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Abstract 


Wireless LAN product architectures have evolved from single 
autonomous access points to systems consisting of a central 
Access Controller (AC) and Wireless Termination Points (WTP 


March 2009 


ized 
s). The 


general goal of centralized control architectures is to move access 
control, including user authentication and authorization, mobility 


management, and radio management from the single access poi 
centralized controller. 


This specification defines the Control And Provisioning of 
Access Points (CAPWAP) Protocol Binding Specification for u 
the IEEE 802.11 Wireless Local Area Network protocol. 
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1. Introduction 


The CAPWAP protocol [RFC5415] defines an extensible protocol to allow 
an Access Controller to manage wireless agnostic Wireless Termination 
Points. The CAPWAP protocol itself does not include any specific 
wireless technologies; instead, it relies on a binding specification 
to extend the technology to a particular wireless technology. 


This specification defines the Control And Provisioning of Wireless 
Access Points (CAPWAP) Protocol Binding Specification for use with 
the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP 
control message fields, new control messages, and message elements 
are defined. The minimum required definitions for a binding-specific 
Statistics message element, Station message element, and WTP Radio 
Information message element are included. 


Note that this binding only supports the IEEE 802.11-2007 
specification. Of note, this binding does not support the ad hoc 
network mode defined in the IEEE 802.11-2007 standard. This 
specification also does not cover the use of data frames with the 
four-address format, commonly referred to as Wireless Bridges, whose 


= 


use is not specified in the IEEE 802.11-2007 standard. This protocol 
specification does not currently officially support IEEE 802.11n. 
That said, the protocol does allow a WTP to advertise support for an 
IEEE 802.11n radio; however, the protocol does not allow for any of 
the protocol’s additional features to be configured and/or used. New 
IEEE protocol specifications published outside of this document 
(e.g., IEEE 802.11v, IEEE 802.11r) are also not supported through 
this binding, and in addition to IEEE 802.11n, must be addressed 
either through a separate CAPWAP binding, or an update to this 
binding. 
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In order to address immediate market needs for standards still being 
developed by the IEEE 802.11 standards body, the WiFi Alliance 
created interim pseudo-standards specifications. Two such 
specifications are widely used in the industry, namely the WiFi 
Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. 
Given their widespread adoption, this CAPWAP binding requires the use 
of these two specifications. 


1.1. Goals 


The goals of this CAPWAP protocol binding are to make the 
capabilities of the CAPWAP protocol available for use in conjunction 
with IEEE 802.11 wireless networks. The capabilities to be made 
available can be summarized as: 


1. To centralize the authentication and policy enforcement functions 
for an IEEE 802.11 wireless network. The AC may also provide 
centralized bridging, forwarding, and encryption of user traffic. 
Centralization of these functions will enable reduced cost and 
higher efficiency by applying the capabilities of network 
processing silicon to the wireless network, as in wired LANs. 


2. To enable shifting of the higher-level protocol processing from 
the WIP. This leaves the time-critical applications of wireless 
control and access in the WTP, making efficient use of the 
computing power available in WTPs that are subject to severe cost 
pressure. 


The CAPWAP protocol binding extensions defined herein apply solely to 
the interface between the WIP and the AC. Inter-AC and station-to-AC 
communication are strictly outside the scope of this document. 


1.2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


1.3. Terminology 
This section contains definitions for terms used frequently 
throughout this document. However, many additional definitions can 
be found in [IEEE.802-11.2007]. 
Access Controller (AC): The network entity that provides WIP access 


to the network infrastructure in the data plane, control plane, 
management plane, or a combination therein. 
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Basic Service Set (BSS): A set of stations controlled by a single 
coordination function. 


Distribution: The service that, by using association information, 
delivers medium access control (MAC) service data units (MSDUs) 
within the distribution system (DS). 


Distribution System Service (DSS): The set of services provided by 
the distribution system (DS) that enable the medium access control 
(MAC) layer to transport MAC service data units (MSDUs) between 
stations that are not in direct communication with each other over a 
single instance of the wireless medium (WM). These services include 
the transport of MSDUs between the access points (APs) of basic 
service sets (BSSs) within an extended service set (ESS), transport 
of MSDUs between portals and BSSs within an ESS, and transport of 
MSDUs between stations in the same BSS in cases where the MSDU has a 
multicast or broadcast destination address, or where the destination 
is an individual address but the station sending the MSDU chooses to 
involve the DSS. DSSs are provided between pairs of IEEE 802.11 
MACs. 


Integration: The service that enables delivery of medium access 
control (MAC) service data units (MSDUs) between the distribution 
system (DS) and an existing, non-IEEE 802.11 local area network (via 
a portal). 


Station (STA): A device that contains an IEEE 802.11 conformant 
medium access control (MAC) and physical layer (PHY) interface to the 
wireless medium (WM). 


Portal: The logical point at which medium access control (MAC) 
service data units (MSDUs) from a non-IEEE 802.11 local area network 
(LAN) enter the distribution system (DS) of an extended service set 
(ESS). 


WLAN: In this document, WLAN refers to a logical component 
instantiated on a WTP device. A single physical WTP may operate a 
number of WLANs. Each Basic Service Set Identifier (BSSID) and its 
constituent wireless terminal radios is denoted as a distinct WLAN on 
a physical WIP. 


Wireless Termination Point (WIP): The physical or network entity that 
contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 
receive station traffic for wireless access networks. 
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2. IEEE 802.11 Binding 


This section describes use of the CAPWAP protocol with the IEEE 
802.11 Wireless Local Area Network protocol, including Local and 
Split MAC operation, Group Key Refresh, Basic Service Set 
Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management 
frame Quality of Service (Qos) tagging and Run State operation. 


2.1. CAPWAP Wireless Binding Identifier 


The CAPWAP Header, defined in Section 4.3 of [RFC5415] requires that 
all CAPWAP binding specifications have a Wireless Binding Identifier 
(WBID) assigned. This document, which defines the IEEE 802.11 
binding, uses the value one (1). 


2.2. Split MAC and Local MAC Functionality 
The CAPWAP protocol, when used with IEEE 802.11 devices, requires 


specific behavior from the WTP and the AC to support the required 
IEEE 802.11 protocol functions. 


For both the Split and Local MAC approaches, the CAPWAP functions, as 
defined in the taxonomy specification [RFC4118], reside in the AC. 


To provide system component interoperability, the WTP and AC MUST 
support 802.11 encryption/decryption at the WTP. The WIP and AC MAY 
support 802.11 encryption/decryption at the AC. 


2.2.1. Split MAC 
This section shows the division of labor between the WIP and the AC 


in a Split MAC architecture. Figure 1 shows the separation of 
functionality between CAPWAP components. 
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Function Location 
Distribution Service AC 
Integration Service AC 
Beacon Generation WTP 
Probe Response Generation WTP 
Power Mgmt/Packet Buffering WTP 
Fragmentation/Defragmentation WTP/AC 
Assoc/Disassoc/Reassoc AC 


IEEE 802.11 QoS 


Classifying AC 
Scheduling WTP/AC 
Queuing WTP 


IEEE 802.11 RSN 


IEEE 802.1X/EAP AC 
RSNA Key Management AC 
IEEE 802.11 Encryption/Decryption WTP/AC 


Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 


In a Split MAC Architecture, the Distribution and Integration 
services reside on the AC, and therefore all user data is tunneled 
between the WTP and the AC. As noted above, all real-time IEEE 
802.11 services, including the Beacon and Probe Response frames, are 
handled on the WTP. 


All remaining IEEE 802.11 MAC management frames are supported on the 
AC, including the Association Request frame that allows the AC to be 
involved in the access policy enforcement portion of the IEEE 802.11 
protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible 
Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security 
Network Association (RSNA) Key Management [IEEE.802-11.2007] 
functions are also located on the AC. This implies that the 
Authentication, Authorization, and Accounting (AAA) client also 
resides on the AC. 


While the admission control component of IEEE 802.11 resides on the 
AC, the real-time scheduling and queuing functions are on the WTP. 
Note that this does not prevent the AC from providing additional 
policy and scheduling functionality. 


Note that in the following figure, the use of ’( - )’ indicates that 


processing of the frames is done on the WIP. This figure represents 
a case where encryption services are provided by the AC. 
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Client WTP AC 


Beacon 


Station Configuration Request 
[Add Station (Station MAC 
Address), IEEE 802.11 Add 
Station (WLAN ID), IEEE 
802.11 Session Key (Flag=A) ] 


Station Configuration Request 
[Add Station(Station MAC 
Address), IEEE 802.11 Add 
Station (WLAN ID), IEEE 802.11 
Station Session Key (Flag=C) ] 


<-------------------------- > 
802.11 Action Frames 
a_a > 
802.11 DATA (1) 
Kern h es E > 


Figure 2: Split MAC Message Flow 


Figure 2 provides an illustration of the division of labor in a Split 
MAC architecture. In this example, a WLAN has been created that is 
configured for IEEE 802.11, using 802.1X-based end user 
authentication and Advanced Encryption Standard-Counter Mode with 
CBC-MAC Protocol (AES-CCMP) link layer encryption (CCMP, see 
[FIPS.197.2001]). The following process occurs: 


o The WTP generates the IEEE 802.11 Beacon frames, using information 
provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 
message element, including the Robust Security Network Information 
Element (RSNIE), which indicates support of 802.1X and AES-CCMP. 


O The WTP processes the Probe Request frame and responds with a 
corresponding Probe Response frame. The Probe Request frame is 
then forwarded to the AC for optional processing. 
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o The WTP forwards the IEEEE 802.11 Authentication and Association 
frames to the AC, which is responsible for responding to the 
client. 


o Once the association is complete, the AC transmits a Station 
Configuration Request message, which includes an Add Station 
message element, to the WIP (see Section 4.6.8 in [RFC5415]). In 
the above example, the WLAN was configured for IEEE 802.1X, and 
therefore the IEEE 802.11 Station Session Key is included with the 
flag field’s 'A” bit set. 


o If the WIP is providing encryption/decryption services, once the 
client has completed the IEEE 802.11 key exchange, the AC 
transmits another Station Configuration Request message, which 
includes: 


An Add Station message element. 


- An IEEE 802.11 Add Station message element, which includes the 
WLAN Identifier with which the station has associated. 


- An IEEE 802.11 Station Session Key message element, which 
includes the pairwise encryption key. 


- An IEEE 802.11 Information Element message element, which 
includes the Robust Security Network Information Element 
(RSNIE) to the WIP, stating the security policy to enforce for 
the client (in this case AES-CCMP). 


o If the WIP is providing encryption/decryption services, once the 
client has completed the IEEE 802.11 key exchange, the AC 
transmits another Station Configuration Request message, which 
includes: 


An Add Station message element. 


- An IEEE 802.11 Add Station message element, which includes the 
WLAN Identifier with which the station has associated. 


- An IEEE 802.11 Station Session Key message element, which 
includes the pairwise encryption key. 


- An IEEE 802.11 Information Element message element, which 
includes the Robust Security Network Information Element 
(RSNIE) to the WIP, stating the security policy to enforce for 
the client (in this case AES-CCMP). 
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o If the AC is providing encryption/decryption services, once the 
client has completed the IEEE 802.11 key exchange, the AC 
transmits another Station Configuration Request message, which 
includes: 


- An Add Station message element. 


- An IEEE 802.11 Add Station message element, which includes the 
WLAN Identifier with which the station has associated. 


- An IEEE 802.11 Station Session Key message element with the 
flag field’s 'C” bit enabled (indicating that the AC will 
provide crypto services). 


o The WIP forwards any IEEE 802.11 Management Action frames received 
to the AC. 


o All IEEE 802.11 station data frames are tunneled between the WTP 
and the AC. 


Note that during the EAP over LAN (EAPOL)-Key exchange between the 
Station and the AC, the Receive Sequence Counter (RSC) field for the 
Group Key (GTK) needs to be included in the frame. The value of zero 
(0) is used by the AC during this exchange. Additional details are 
available in Section 9.1. 


The WIP SHALL include the IEEE 802.11 MAC header contents in all 
frames transmitted to the AC. 


When 802.11 encryption/decryption is performed at the WTP, the WTP 
MUST decrypt the uplink frames, MUST set the Protected Frame field to 
0, and MUST make the frame format consistent with that of an 
unprotected 802.11 frame prior to transmitting the frames to the AC. 
The fields added to an 802.11 protected frame (i.e., Initialization 
Vector/Extended Initialization Vector (IV/EIV), Message Integrity 
Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off 
prior to transmission from the WIP to AC. For downlink frames, the 
Protected Frame field MUST be set to 0 by the AC as the frame being 
sent is unencrypted. The WIP MUST apply the required protection 
policy for the WLAN, and set the Protected Frame field on 
transmission over the air. The Protected Frame field always needs to 
accurately indicate the status of the 802.11 frame that is carrying 
Tts 


When 802.11 encryption/decryption is performed at the AC, the WTP 
SHALL NOT decrypt the uplink frames prior to transmitting the frames 
to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 
fields as described in Figure 3. 
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MAC header field Location 
Frame Control: 
Version AC 
ToDS AC 
FromDS AC 
Type AC 
SubType AC 
MoreFrag WIP/AC 
Retry WTP 
Pwr Mgmt = 
MoreData WTP 
Protected WTP/AC 
Order AC 
Duration: WTP 
Address 1: AC 
Address 2: AC 
Address 3: AC 
Sequence Ctrl: WTP 
Address 4: AC 
QoS Control: AC 
Frame Body: AC 
FCS: WTP 


Figure 3: Population of the IEEE 802.11 MAC Header Fields for 
Downlink Frames 


When 802.11 encryption/decryption is performed at the AC, the 
MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 
applicable to downlink frames, and is set to 0. Note that the Frame 
Check Sequence (FCS) field is not included in 802.11 frames exchanged 
between the WTP and the AC. Upon sending data frames to the AC, the 
WIP is responsible for validating and stripping the FCS field. Upon 
receiving data frames from the AC, the WIP is responsible for adding 
the FCS field, and populating the field as described in 
[IEEE.802-11.2007]. 


Note that when the WTP tunnels data packets to the AC (and vice 
versa), the CAPWAP protocol does not guarantee in-order delivery. 
When the protocol being transported over IEEE 802.11 is IP, out-of- 
order delivery is not an issue as IP has no such requirements. 
However, implementers need to be aware of this protocol 
characteristic before deciding to use CAPWAP. 


2.2.2. Local MAC 
This section shows the division of labor between the WTP and the AC 


in a Local MAC architecture. Figure 4 shows the separation of 
functionality among CAPWAP components. 
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Function Location 
Distribution Service WTP/AC 
Integration Service WTP 
Beacon Generation WTP 
Probe Response Generation WTP 
Power Mgmt/Packet Buffering WTP 
Fragmentation/Defragmentation WTP 
Assoc/Disassoc/Reassoc WTP/AC 


IEEE 802.11 QoS 


Classifying WTP 
Scheduling WTP 
Queuing WTP 


IEEE 802.11 RSN 


IEEE 802.1X/EAP AC 
RSNA Key Management AC 
IEEE 802.11 Encryption/Decryption WTP 


Figure 4: Mapping of 802.11 Functions for Local AP Architecture 


In the Local MAC mode, the integration service exists on the WTP, 
while the distribution service MAY reside on either the WTP or the 
AC. When it resides on the AC, station-generated frames are not 
forwarded to the AC in their native format, but encapsulated as 802.3 
frames. 


While the MAC is terminated on the WTP, it is necessary for the AC to 
be aware of mobility events within the WTPs. Thus, the WTP MUST 
forward the IEEE 802.11 Association Request frames to the AC. The AC 
MAY reply with a failed Association Response frame if it deems it 
necessary, and upon receipt of a failed Association Response frame 
from the AC, the WTP MUST send a Disassociation frame to the station. 


The IEEE 802.1X [IEEE.802-1X.2004], EAP, and IEEE RSNA Key Management 
[IEEE.802-11.2007] functions reside in the AC. Therefore, the WTP 
MUST forward all IEEE 802.1X, EAP, and RSNA Key Management frames to 
the AC and forward the corresponding responses to the station. This 
implies that the AAA client also resides on the AC. 


Note that in the following figure, the use of ’( - )’ indicates that 
processing of the frames is done on the WTP. 
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Client WTP AC 
Beacon 

< AAA Se pank let Sepsis nes et ERA em ll eggs aad seep aÀ 
Probe 

<---------------------------- > 


<--------------------------- (Se ee ee ee a ees > 
Station Configuration Request 
[Add Station (Station MAC 
Address), IEEE 802.11 Add 
Station (WLAN ID), IEEE 
802.11 Session Key (Flag=A) ] 


Station Configuration Request 
[Add Station(Station MAC 
Address), IEEE 802.11 Add 
Station (WLAN ID), IEEE 802.11 
Station session Key (Key=x), 
IEEE 802.11 Information 
Element (RSNIE (Pairwise 
Cipher=CCMP) ) ] 


Figure 5: Local MAC Message Flow 


Figure 5 provides an illustration of the division of labor in a Local 
MAC architecture. In this example, a WLAN that is configured for 
IEEE 802.11 has been created using AES-CCMP for privacy. The 
following process occurs: 


o The WIP generates the IEEE 802.11 Beacon frames, using information 
provided to it through the Add WLAN (see Section 6.1) message 


element. 


o The WTP processes a Probe Request frame and responds with a 
corresponding Probe Response frame. 


o The WIP forwards the IEEE 802.11 Authentication and Association 
frames to the AC. 
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o Once the association is complete, the AC transmits a Station 
Configuration Request message, which includes the Add Station 
message element, to the WIP (see Section 4.6.8 in [RFC5415]). In 
the above example, the WLAN was configured for IEEE 802.1X, and 
therefore the IEEE 802.11 Station Session Key is included with the 
flag field's 'A” bit set. 


o The WIP forwards all IEEE 802.1X and IEEE 802.11 key exchange 
messages to the AC for processing. 


o The AC transmits another Station Configuration Request message, 
which includes: 


- An Add Station message element, which MAY include a Virtual LAN 
(VLAN) [IEEE.802-10.2005] name, which when present is used by 
the WTP to identify the VLAN on which the user's data frames 
are to be bridged. 


- An IEEE 802.11 Add Station message element, which includes the 
WLAN Identifier with which the station has associated. 


- An IEEE 802.11 Station Session Key message element, which 
includes the pairwise encryption key. 


- An IEEE 802.11 Information Element message element, which 
includes the RSNIE to the WIP, stating the security policy to 
enforce for the client (in this case AES-CCMP). 


o The WIP forwards any IEEE 802.11 Management Action frames received 
to the AC. 


o The WIP MAY locally bridge client data frames (and provide the 
necessary encryption and decryption services). The WIP MAY also 
tunnel client data frames to the AC, using 802.3 frame tunnel mode 
or 802.11 frame tunnel mode. 


2.3. Roaming Behavior 


This section expands upon the examples provided in the previous 
section, and describes how the CAPWAP control protocol is used to 
provide secure roaming. 


Once a client has successfully associated with the network ina 
secure fashion, it is likely to attempt to roam to another WTP. 
Figure 6 shows an example of a currently associated station moving 
from its "Old WTP" to a "New WIP". The figure is valid for multiple 
different security policies, including IEEE 802.1X and Wireless 
Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]. 
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In the event that key caching was employed, the 802.1X Authentication 
step would be eliminated. Note that the example represents one where 
crypto services are provided by the WTP, so in a case where the AC 
provided this function the last Station Configuration Request would 
be different. 


Client Old WTP New WTP AC 
Association Request/Response 


Station Configuration Request 
[Add Station (Station MAC 
Address), IEEE 802.11 Add 
Station (WLAN ID), IEEE 
802.11 Session Key (Flag=A) ] 


<---------------- > 
802.1X Authentication (if no key cache entry exists) 
PIPE A AE C ser jesstn Sesia > 
802.11 4-way Key Exchange 
ae ee eee A A (a esroriis==== > 


Station Configuration Request 
[Delete Station] 


Station Configuration Request 
[Add Station(Station MAC 
Address), IEEE 802.11 Add 
Station (WLAN ID), IEEE 802.11 
Station session Key (Key=x), 
IEEE 802.11 Information 
Element (RSNIE (Pairwise 
Cipher=CCMP) ) ] 


Figure 6: Client Roaming Example 
2.4. Group Key Refresh 


Periodically, the Group Key (GTK) for the BSS needs to be updated. 
The AC uses an EAPOL-Key frame to update the group key for each STA 
in the BSS. While the AC is updating the GTK, each Layer 2 (L2) 
broadcast frame transmitted to the BSS needs to be duplicated and 
transmitted using both the current GTK and the new GTK. Once the GTK 
update process has completed, broadcast frames transmitted to the BSS 
will be encrypted using the new GTK. 


In the case of Split MAC, the AC needs to duplicate all broadcast 
packets and update the key index so that the packet is transmitted 
using both the current and new GTK to ensure that all STAs in the BSS 
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receive the broadcast frames. In the case of Local MAC, the WTP 
needs to duplicate and transmit broadcast frames using the 
appropriate index to ensure that all STAs in the BSS continue to 
receive broadcast frames. 


The Group Key update procedure is shown in the following figure. The 
AC will signal the update to the GTK using an IEEE 802.11 
Configuration Request message, including an IEEE 802.11 Update WLAN 
message element with the new GTK, its index, the Transmit Sequence 
Counter (TSC) for the Group Key and the Key Status set to 3 (begin 
GTK update). The AC will then begin updating the GTK for each STA. 
During this time, the AC (for Split MAC) or WIP (for Local MAC) MUST 
duplicate broadcast packets and transmit them encrypted with both the 
current and new GTK. When the AC has completed the GTK update to all 
STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration 
Request message including an IEEE 802.11 Update WLAN message element 
containing the new GTK, its index, and the Key Status set to 4 (GTK 
update complete). 


Client WTP AC 
TEEE 802.11 WLAN Configuration Request [Update 
WLAN (GTK, GTK Index, GTK Start, 
Group TSC) ] 
802.1X EAPoL (GTK Message 1) 


802.1X EAPoL (GTK Message 2) 


IEEE 802.11 WLAN Configuration Request [ Update 
WLAN (GTK Index, GTK Complete) ] 


Figure 7: Group Key Update Procedure 
2.5. BSSID to WLAN ID Mapping 


The CAPWAP protocol binding enables the WIP to assign BSSIDs upon 
creation of a WLAN (see Section 6.1). While manufacturers are free 
to assign BSSIDs using any arbitrary mechanism, it is advised that 
where possible the BSSIDs are assigned as a contiguous block. 


When assigned as a block, implementations can still assign any of the 
available BSSIDs to any WLAN. One possible method is for the WTP to 

assign the address using the following algorithm: base BSSID address 

+ WLAN ID. 
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The WIP communicates the maximum number of BSSIDs that it supports 
during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 
message element (see Section 6.23). 


2.6. CAPWAP Data Channel QoS Behavior 


The CAPWAP IEEE 802.11 binding specification provides procedures to 
allow for the WIP to enforce Quality of Service on IEEE 802.11 Data 
Frames and MAC Management messages. 


2.6.1. IEEE 802.11 Data Frames 


When the WLAN is created on the WTP, a default Quality of Service 
policy is established through the IEEE 802.11 WTP Quality of Service 
message element (see Section 6.22). This default policy will cause 
the WIP to use the default QoS values for any station associated with 
the WLAN in question. The AC MAY also override the policy for a 
given station by sending the IEEE 802.11 Update Station QoS message 
element (see Section 6.20), known as a station-specific QoS policy. 


Beyond the default, and per station QoS policy, the IEEE 802.11 
protocol also allows a station to request special QoS treatment for a 
specific flow through the Traffic Specification (TSPEC) Information 
Elements found in the IEEE 802.11-2007’s QoS Action Frame. 
Alternatively, stations MAY also use the WiFi Alliance’s WMM 
specification instead to request QoS treatment for a flow (see 
[WMM]). This requires the WIP to observe the Status Code in the IEEE 
802.11-2007 and WMM QoS Action Add Traffic System (ADDTS) responses 
from the AC, and provide the services requested in the TSPEC 
Information Element. Similarly, the WTP MUST observe the Reason Code 
Information Element in the IEEE 802.11-2007 and WMM QoS Action DELTS 
responses from the AC by removing the policy associated with the 
TSPEC. 


The IEEE 802.11 WTP Quality of Service message element's Tagging 
Policy field indicates how the packets are to be tagged, known as the 
Tagging Policy. There are five bits defined, two of which are used 
to indicate the type of QoS to be used by the WIP. The first is the 
'P’ bit, which is set to inform the WIP it is to use the 802.1p QoS 
mechanism. When set, the ’Q’ bit is used to inform the WTP which 
802.1p priority values it is to use. 


The 'D” bit is set to inform the WIP it is to use the Differentiated 
Services Code Point (DSCP) QoS mechanism. When set, the ’I’ and ’0’ 
bits are used to inform the WIP which values it is to use in the 
inner header, in the station’s original packet, or the outer header, 
the latter of which is only valid when tunneling is enabled. 
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When an IEEE 802.11 Update Station QoS message element is received, 
while the specific 802.1p priority or DSCP values may change for a 
given station, known as the station specific policy, the original 
Tagging Policy (the use of the five bits) remains the same. 


The use of the DSCP and 802.1p QoS mechanisms are not mutually 
exclusive. An AC MAY request that a WIP use none, one, or both types 
of QoS mechanisms at the same time. 


2.6.1.1. 802.1p Support 


The IEEE 802.11 WIP Quality of Service and IEEE 802.11 Update Station 
QoS message elements include the "802.1p Tag" field, which is the 
802.1p priority value. This value is used by the WTP by adding an 
802.10 header (see [IEEE.802-10.2005]) with the priority field set 
according to the policy provided. Note that this tagging is only 
valid for interfaces that support 802.1p. The actual treatment does 
not change for either Split or Local MAC modes, or when tunneling is 
used. The only exception is when tunneling is used, the 802.10 
header is added to the outer packet (tunneled) header. The IEEE 
802.11 standard does not permit the station's packet to include an 
802.10 header. Instead, the QoS mechanisms defined in the IEEE 
802.11 standard are used by stations to mark a packet's priority. 
When the ’P’ bit is set in the Tagging Policy, the ’Q’ bit has the 
following behavior: 


Q=1: The WIP marks the priority field in the 802.10 header to 
either the default or the station-specific 802.1p policy. 


Q=0: The WIP marks the priority field in the 802.10 header to the 
value found in the User Priority field of the QoS Control 
field of the IEEE 802.11 header. If the QoS Control field is 
not present in the IEEE 802.11 header, then the behavior 
described under 'Q=1' is used. 


2.6.1.2. DSCP Support 


The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 
QoS message elements also provide a "DSCP Tag", which is used by the 
WIP when the 'D” bit is set to mark the DSCP field of both the IPv4 
and IPv6 headers (see [RFC2474]). When DSCP is used, the WIP marks 
the inner packet (the original packet received by the station) when 
the 'I' bit is set. Similarly, the WIP marks the outer packet 
(tunnel header’s DSCP field) when the 'O0” bit is set. 


When the 'D” bit is set, the treatment of the packet differs based on 


whether the WIP is tunneling the station’s packets to the AC. 
Tunneling does not occur in a Local MAC mode when the AC has 
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communicated that tunneling is not required, as part of the IEEE 
802.11 Add WLAN message element, see Section 6.1. In the case where 
tunneling is not used, the ’I’ and O’ bits have the following 
behaviors: 


O=1: This option is invalid when tunneling is not enabled for 
station data frames. 


O=0: This option is invalid when tunneling is not enabled for 
station data frames. 


I=1: The WIP sets the DSCP field in the station’s packet to either 
the default policy or the station-specific policy if one 
exists. 

I=0: The WIP MUST NOT modify the DSCP field in the station's 
packet. 


For Split MAC mode, or Local MAC with tunneling enabled, the WTP 
needs to contend with both the inner packet (the station's original 
packet) as well as the tunnel header (added by the WTP). In this 
mode of operation, the bits are treated as follows: 


O=1: The WIP sets the DSCP field in the tunnel header to either the 
default policy or the station specific policy if one exists. 


O=0: The WIP sets the DSCP field in the tunnel header to the value 
found in the inner packet’s DSCP field. If encryption 
services are provided by the AC (see Section 6.15), the packet 
is encrypted; therefore, the WIP cannot access the inner DSCP 
field, in which case it uses the behavior described when the 
'O’ bit is set. This occurs also if the inner packet is not 
IPv4 or IPv6, and thus does not have a DSCP field. 


I=1: The WIP sets the DSCP field in the station’s packet to either 
the default policy or the station-specific policy if one 
exists. If encryption services are provided by the AC (see 
Section 6.15), the packet is encrypted; therefore, the WTP 
cannot access the inner DSCP field, in which case it uses the 
behavior described when the ’I’ bit is not set. This occurs 
also if the inner packet is not IPv4 or IPv6, and thus does 
not have a DSCP field. 


I=0: The WIP MUST NOT modify the DSCP field in the station's 
packet. 
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The CAPWAP protocol supports the Explicit Congestion Notification 
(ECN) bits [RFC3168]. Additional details on ECN support can be found 
in [RFC5415]. 


2.6.2. IEEE 802.11 MAC Management Messages 


It is recommended that IEEE 802.11 MAC Management frames be sent by 
both the AC and the WTP with appropriate Quality of Service values, 
listed below, to ensure that congestion in the network minimizes 
occurrences of packet loss. Note that the QoS Mechanism specified in 
the Tagging Policy is used as specified by the AC in the IEEE 802.11 
WTP Quality of Service message element (see Section 6.22). However, 
the station-specific policy is not used for IEEE 802.11 MAC 
Management frames. 


802.1p: The precedence value of 7 (decimal) SHOULD be used for all 
IEEE 802.11 MAC management frames, except for Probe 
Requests, which SHOULD use 4. 


DSCP: All IEEE 802.11 MAC management frames SHOULD use the CS6 
per- hop behavior (see [RFC2474]), while IEEE 802.11 Probe 
Requests should use the Low Drop Assured Forwarding per-hop 
behavior (see [RFC3246]). 


2.7. Run State Operation 


The Run state is the normal state of operation for the CAPWAP 
protocol in both the WIP and the AC. 


When the WIP receives a WLAN Configuration Request message (see 
Section 3.1), it MUST respond with a WLAN Configuration Response 
message (see Section 3.2), and it remains in the Run state. 


When the AC sends a WLAN Configuration Request message (see 
Section 3.1) or receives the corresponding WLAN Configuration 
Response message (see Section 3.2) from the WIP, it remains in the 
Run state. 


3. IEEE 802.11 Specific CAPWAP Control Messages 


This section defines CAPWAP Control messages that are specific to the 
IEEE 802.11 binding. Two messages are defined: IEEE 802.11 WLAN 
Configuration Request and IEEE 802.11 WLAN Configuration Response. 
See Section 4.5 in [RFC5415] for CAPWAP Control message definitions 
and the derivation of the Message Type value from the IANA Enterprise 
number. 
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The valid message types for IEEE 802.11-specific control messages are 
listed below. The IANA Enterprise number used with these messages is 


13277. 
CAPWAP Control Message Message Type 
Value 
IEEE 802.11 WLAN Configuration Request 3398913 
IEEE 802.11 WLAN Configuration Response 3398914 


3.1. IEEE 802.11 WLAN Configuration Request 


The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 


WTP in order to change services provided by the WIP. This control 
message is used to either create, update, or delete a WLAN on the 
WIP. 


The IEEE 802.11 WLAN Configuration Request is sent as a result of 
either some manual administrative process (e.g., deleting a WLAN), or 
automatically to create a WLAN on a WIP. When sent automatically to 
create a WLAN, this control message is sent after the CAPWAP 
Configuration Update Response message (see Section 8.5 in [RFC5415]) 
has been received by the AC. 


Upon receiving this control message, the WTP will modify the 
necessary services and transmit an IEEE 802.11 WLAN Configuration 
Response. 


A WTP MAY provide service for more than one WLAN; therefore, every 
WLAN is identified through a numerical index. For instance, a WTP 
that is capable of supporting up to 16 Service Set Identifiers 
(SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request 
messages that include the Add WLAN message element. 


Since the index is the primary identifier for a WLAN, an AC MAY 
attempt to ensure that the same WLAN is identified through the same 
index number on all of its WIPs. An AC that does not follow this 
approach MUST find some other means of maintaining a WLAN-Identifier- 
to-SSID mapping table. 


The following message elements MAY be included in the IEEE 802.11 
WLAN Configuration Request message. Only one message element MUST be 
present. 


o IEEE 802.11 Add WLAN, see Section 6.1 


o IEEE 802.11 Delete WLAN, see Section 6.4 
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o IEEE 802.11 Update WLAN, see Section 6.21 

The following message element MAY be present. 

o IEEE 802.11 Information Element, see Section 6.6 
o Vendor-Specific Payload, see [RFC5415] 


3.2. IEEE 802.11 WLAN Configuration Response 


The IEEE 802.11 WLAN Configuration Response message is sent by the 
WIP to the AC. It is used to acknowledge receipt of an IEEE 802.11 
WLAN Configuration Request message, and to indicate that the 
requested configuration was successfully applied or that an error 
related to the processing of the IEEE 802.11 WLAN Configuration 
Request message occurred on the WTP. 


The following message element MUST be included in the IEEE 802.11 
WLAN Configuration Response message. 


o Result Code, see Section 4.6.34 in [RFC5415] 


The following message element MAY be included in the IEEE 802.11 WLAN 
Configuration Response message. 


o IEEE 802.11 Assigned WIP BSSID, see Section 6.3 
o Vendor-Specific Payload, see [RFC5415] 
4. CAPWAP Data Message Bindings 


This section describes the CAPWAP data message bindings to support 
transport of IEEE 802.11 frames. 


Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 
message, which is used to encapsulate a wireless payload. For 
TEEE 802.11, the IEEE 802.11 header and payload are encapsulated 
(excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 
checksum is handled by the WIP. This allows the WIP to validate 
an IEEE 802.11 frame prior to sending it to the AC. Similarly, 
when an AC wishes to transmit a frame to a station, the WTP 
computes and adds the FCS checksum. 


Optional Wireless Specific Information: This optional CAPWAP header 
field (see Section 4.3 in [RFC5415]) is only used with CAPWAP data 
messages, and it serves two purposes, depending upon the direction 
of the message. For messages from the WIP to the AC, the field 
uses the format described in the "IEEE 802.11 Frame Info" field 
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(see below). However, for messages sent by the AC to the WTP, the 
format used is described in the "Destination WLANs" field (also 
defined below). 


Note that in both cases, the two optional headers fit in the 
"Data" field of the Wireless Specific Information header. 


IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 
station over the air, it is encapsulated and this field is used to 
include radio and PHY-specific information associated with the 
frame. 


The IEEE 802.11 Frame Info field has the following format: 


0 1 2 3 

CLAVQS45 67 SFO 1L23 45 67:8 9012345 6 7 89:0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| RSSI | SNR | Data Rate | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


RSSI: Received Signal Strength Indication (RSSI) is a signed, 
8-bit value. It is the received signal strength indication, in 
dBm. 

SNR: SNR is a signed, 8-bit value. It is the signal-to-noise 


ratio of the received IEEE 802.11 frame, in dB. 


Data Rate: The data rate field is a 16-bit unsigned value. The 
data rate field is a 16-bit unsigned value expressing the data 
rate of the packets received by the WTP in units of 0.1 Mbps. 
For instance, a packet received at 5.5 Mbps would be set to 55, 
while 11 Mbps would be set to 110. 


Destination WLANs: The Destination WLANs field is used to specify 
the target WLANs for a given frame, and is only used with 
broadcast and multicast frames. This field allows the AC to 
transmit a single broadcast or multicast frame to the WIP and 
allows the WIP to perform the necessary frame replication. The 
field uses the following format: 


0 1 2 3 
0.102 E By OF BQO 2 BA SOF 8G O64 ZA bs 6 8 QOL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 

| WLAN ID bitmap | Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
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WLAN ID bitmap: This bit field indicates the WLAN ID (see 
Section 6.1) on which the WIP will transmit the included frame. 
For instance, if a multicast packet is to be transmitted on 
WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be 
enabled. WLAN 1 is represented by bit 15 in the figure above, 
or the least significant bit, while WLAN 16 would be 
represented by bit zero (0), or the most significant bit, in 


the figure. This field is to be set to all zeroes for unicast 
packets and is unused if the WIP is not providing IEEE 802.11 
encryption. 

Reserved: All implementations complying with this protocol MUST 


set to zero any bits that are reserved in the version of the 
protocol supported by that implementation. Receivers MUST 
ignore all bits not defined for the version of the protocol 


they support. 
5. CAPWAP Control Message Bindings 


This section describes the IEEE 802.11-specific message 
included in CAPWAP Control Messages. 


5.1. Discovery Request Message 


The following IEEE 802.11-specific message element MUST 
in the CAPWAP Discovery Request Message. 


o IEEE 802.11 WIP Radio Information, see Section 6.25. 
802.11 WIP Radio Information message element MUST be 
every radio in the WIP. 


5.2. Discovery Response Message 


The following IEEE 802.11-specific message element MUST 
in the CAPWAP Discovery Response Message. 


o IEEE 802.11 WIP Radio Information, see Section 6.25. 
802.11 WIP Radio Information message element MUST be 
every radio in the WIP. 


5.3. Primary Discovery Request Message 


The following IEEE 802.11 specific message element MUST 
in the CAPWAP Primary Discovery Request message. 


o IEEE 802.11 WIP Radio Information, see Section 6.25. 


802.11 WIP Radio Information message element MUST be 
every radio in the WTP. 
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5.4. Primary Discovery Response Message 


The following IEEE 802.11-specific message element MUST be included 
in the CAPWAP Primary Discovery Response message. 


o IEEE 802.11 WIP Radio Information, see Section 6.25. An IEEE 
802.11 WIP Radio Information message element MUST be present for 


every radio in the WTP. 


5.5. Join Request Message 


The following IEEE 802.11-specific message element MUST be included 
in the CAPWAP Join Request message. 


o IEEE 802.11 WIP Radio Information, see Section 6.25. An IEEE 
802.11 WIP Radio Information message element MUST be present for 
every radio in the WTP. 


5.6. Join Response Message 


The following IEEE 802.11-specific message element MUST be included 
in the CAPWAP Join Response message. 


o IEEE 802.11 WIP Radio Information, see Section 6.25. An IEEE 
802.11 WIP Radio Information message element MUST be present for 
every radio in the WIP. 

5.7. Configuration Status Request Message 

The following IEEE 802.11-specific message elements MAY be included 

in the CAPWAP Configuration Status Request message. More than one of 

each message element listed MAY be included. 

o IEEE 802.11 Antenna, see Section 6.2 

o IEEE 802.11 Direct Sequence Control, see Section 6.5 

o IEEE 802.11 MAC Operation, see Section 6.7 


o IEEE 802.11 Multi-Domain Capability, see Section 6.9 


o IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) 
Control, see Section 6.10 


o IEEE 802.11 Supported Rates, see Section 6.17 


o IEEE 802.11 Tx Power, see Section 6.18 
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o IEEE 802.11 TX Power Level, see Section 6.19 

o IEEE 802.11 WIP Radio Configuration, see Section 6.23 

o IEEE 802.11 WIP Radio Information, see Section 6.25. An IEEE 
802.11 WIP Radio Information message element MUST be present for 
every radio in the WIP. 

5.8. Configuration Status Response Message 

The following IEEE 802.11 specific message elements MAY be included 

in the CAPWAP Configuration Status Response Message. More than one 

of each message element listed MAY be included. 

o IEEE 802.11 Antenna, see Section 6.2 

o IEEE 802.11 Direct Sequence Control, see Section 6.5 

o IEEE 802.11 MAC Operation, see Section 6.7 

o IEEE 802.11 Multi-Domain Capability, see Section 6.9 


o IEEE 802.11 OFDM Control, see Section 6.10 


o IEEE 802.11 Rate Set, see Section 6.11 


o IEEE 802.11 Supported Rates, see Section 6.17 
o IEEE 802.11 Tx Power, see Section 6.18 
o IEEE 802.11 WTP Quality of Service, see Section 6.22 
o IEEE 802.11 WIP Radio Configuration, see Section 6.23 
5.9. Configuration Update Request Message 
The following IEEE 802.11-specific message elements MAY be included 
in the CAPWAP Configuration Update Request message. More than one of 
each message element listed MAY be included. 
o IEEE 802.11 Antenna, see Section 6.2 
o IEEE 802.11 Direct Sequence Control, see Section 6.5 


o IEEE 802.11 MAC Operation, see Section 6.7 


o IEEE 802.11 Multi-Domain Capability, see Section 6.9 
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o IEEE 802.11 OFDM Control, see Section 6.10 
o IEEE 802.11 Rate Set, see Section 6.11 
o IEEE 802.11 RSNA Error Report from Station, see Section 6.12 
o IEEE 802.11 Tx Power, see Section 6.18 
o IEEE 802.11 WTP Quality of Service, see Section 6.22 
o IEEE 802.11 WIP Radio Configuration, see Section 6.23 
5.10. Station Configuration Request 
The following IEEE 802.11-specific message elements MAY be included 


in the CAPWAP Station Configuration Request message. More than one 
of each message element listed MAY be included. 


o IEEE 802.11 Station, see Section 6.13 

o IEEE 802.11 Station Session Key, see Section 6.15 

o IEEE 802.11 Station QoS Profile, see Section 6.14 

o IEEE 802.11 Update Station Qos, see Section 6.20 
5.11. Change State Event Request 


The following IEEE 802.11-specific message element MAY be included in 
the CAPWAP Station Configuration Request message. 


o IEEE 802.11 WIP Radio Fail Alarm Indication, see Section 6.24 
5.12. WIP Event Request 

The following IEEE 802.11-specific message elements MAY be included 

in the CAPWAP WTP Event Request message. More than one of each 

message element listed MAY be included. 

o IEEE 802.11 MIC Countermeasures, see Section 6.8 


o IEEE 802.11 RSNA Error Report from Station, see Section 6.12 


o IEEE 802.11 Statistics, see Section 6.16 
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The following IEEE 802.11-specific message elements are defined in 
this section. 
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Figure 8: IEEE 802.11 Binding Message Elements 


6.1. IEEE 802.11 Add WLAN 


The IEEE 802.11 Add WLAN message element is used by the AC to define 


a WLAN on the WIP. 


include IEEE 802.11 Information Element message elements, 
the following IEEE 802.11 IEs: 


Power Constraint information element 


EDCA Parameter Set information element 


QoS Capability information element 


Calhoun, 


et al. Standards Track 


The inclusion of this message element MUST also 


containing 
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WPA information element [WPA] 
RSN information element 
WMM information element [WMM] 


These IEEE 802.11 Information Elements are stored by the WTP and 
included in any Probe Responses and Beacons generated, as specified 
in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN 
Information Element is sent with the IEEE 802.11 Add WLAN message 
element to instruct the WTP on the usage of the Key field. 


If cryptographic services are provided at the WTP, the WTP MUST 
observe the algorithm dictated in the Group Cipher Suite field of the 
RSN Information Element sent by the AC. The RSN Information Element 
is used to communicate any supported algorithm, including WEP, 
Temporal Key Integrity Protocol (TKIP) and AES-CCMP. In the case of 
static WEP keys, the RSN Information Element is still used to 
indicate the cryptographic algorithm even though no key exchange 
occurred. 


An AC MAY include additional Information Elements as desired. The 
message element uses the following format: 


0 I 2 3 
0-2-3 4 506.708 9 0T 23A 5 6 FY 89-01-23 A 5:56 17,08: :9 0:41 
Fatt tata tartar tartar dd E E E E 
| Radio ID | WLAN ID | Capability 
Fatt tata tartar tartan dd a E E E 
| Key Index | Key Status | Key Length 
a a dd ad E E E E 
| Key... 
Fatt tata t ata t o dd E A E E 
| Group TSC 
Fat ata ta tata tata tata tata tata tata t ata tatatatatat— 
| Group TSC | Qos 
Fat ata tata tata E 
| MAC Mode | Tunnel Mode | Suppress SSID 
Fata ta ta tata tata E 


—t+—-4+-4+-4+-4+-4+-4- 
Auth Type 
-+-+-+-+-+-+-+— 

SSID 
-+-+-+-+-+-+-+— 


+— +—+—+—+—+ 


+— +— + 


+ 


Type: 1024 for IEEE 802.11 Add WLAN 
Length: >= 20 


Radio ID: An 8-bit value representing the radio, whose value is 
between one (1) and 31. 
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WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 
MUST be between one (1) and 16. 


Capability: A 16-bit value containing the Capability information 
field to be advertised by the WTP in the Probe Request and Beacon 
frames. Each bit of the Capability field represents a different 
WTP capability, which are described in detail in 
[IEEE.802-11.2007]. The format of the field is: 


0 Al 
0123456789012345 


E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 
to 1 
I (IBSS): The AC MUST set the Independent Basic Service Set 


(IBSS) subfield to 0. 


C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 
Pollable) subfield based on the table found in 
[IEEE.802-11.2007]. 


F (CF-Poll Request): The AC sets the CF-Poll Request subfield 
based on the table found in [IEEE.802-11.2007]. 


P (Privacy): The AC sets the Privacy subfield based on the 
confidentiality requirements of the WLAN, as defined in 
[IEEE.802-11.2007]. 


S (Short Preamble): The AC sets the Short Preamble subfield 
based on whether the use of short preambles is permitted on the 
WLAN, as defined in [IEEE.802-11.2007]. 


B (PBCC): The AC sets the Packet Binary Convolutional Code 
(PBCC) modulation option subfield based on whether the use of 
PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007]. 


A (Channel Agility): The AC sets the Channel Agility subfield 
based on whether the WIP is capable of supporting the High Rate 
Direct Sequence Spread Spectrum (HR/DSSS), as defined in 
[IEEE.802-11.2007]. 
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(Spectrum Management): The AC sets the Spectrum Management 
subfield according to the value of the 
dot11SpectrumManagementRequired MIB variable, as defined in 
[IEEE.802-11.2007]. 


(QOS): The AC sets the Quality of Service (QoS) subfield based 
on the table found in [IEEE.802-11.2007]. 


(Short Slot Time): The AC sets the Short Slot Time subfield 
according to the value of the WTP’s currently used slot time 
value, as defined in [IEEE.802-11.2007]. 


(APSD): The AC sets the Automatic Power Save Delivery (APSD) 
subfield according to the value of the 
dot11APSDOptionImplemented Management Information Base (MIB) 
variable, as defined in [IEEE.802-11.2007]. 


(Reserved): The AC sets the Reserved subfield to zero, as 
defined in [IEEE.802-11.2007]. 


(DSSS-OFDM) : The AC sets the DSSS-OFDM subfield to indicate 
the use of Direct Sequence Spread Spectrum with Orthogonal 
Frequency Division Multiplexing (DSSS-OFDM), as defined in 
[IEEE.802-11.2007]. 


(Delayed Block ACK): The AC sets the Delayed Block ACK 
subfield according to the value of the 
dot11DelayedBlockAckOptionImplemented MIB variable, as defined 
in [IEEE.802-11.2007]. 


(Immediate Block ACK): The AC sets the Delayed Block ACK 
subfield according to the value of the 
dot11ImmediateBlockAckOptionImplemented MIB variable, as defined 
in [IEEE.802-11.2007]. 


ndex: The Key Index associated with the key. 

tatus: A l-byte value that specifies the state and usage of 

e key that has been included. Note this field is ignored if the 
y Length field is set to zero (0). The following values 


scribe the key usage and its status: 


- A value of zero, with the inclusion of the RSN Information 
Element means that the WLAN uses per-station encryption keys, 
and therefore the key in the 'Key” field is only used for 
multicast traffic. 
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1 - When set to one, the WLAN employs a shared Wired Equivalent 
Privacy (WEP) key, also known as a static WEP key, and uses 
the encryption key for both unicast and multicast traffic for 
all stations. 


2 - The value of 2 indicates that the AC will begin rekeying the 
GTK with the STA’s in the BSS. It is only valid when IEEE 
802.11 is enabled as the security policy for the BSS. 


3 - The value of 3 indicates that the AC has completed rekeying 
the GTK and broadcast packets no longer need to be duplicated 
and transmitted with both GTK’s. 


Key Length: A 16-bit value representing the length of the Key 
field. 
Key: A Session Key, whose length is known via the Key Length field, 


used to provide data privacy. For encryption schemes that employ 
a separate encryption key for unicast and multicast traffic, the 
key included here only applies to multicast frames, and the cipher 
suite is specified in an accompanied RSN Information Element. In 
these scenarios, the key and cipher information is communicated 
via the Add Station message element, see Section 4.6.8 in 
[RFC5415] and the IEEE 802.11 Station Session Key message element, 
see Section 6.15. When used with WEP, the key field includes the 
broadcast key. When used with CCMP, the Key field includes the 
128-bit Group Temporal Key. When used with TKIP, the Key field 
includes the 256-bit Group Temporal Key (which consists of a 128- 
bit key used as input for TKIP key mixing, and two 64-bit keys 
used for Michael). 


Group TSC: A 48-bit value containing the Transmit Sequence Counter 
(TSC) for the updated group key. The WIP will set the TSC for 
broadcast/multicast frames to this value for the updated group 
key. 


Qos: An 8-bit value specifying the default QoS policy for the WTP 
to apply to network traffic received for a non-WMM enabled STA. 


The following enumerated values are supported: 
0 - Best Effort 


1 - Video 
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2 - Voice 
3 - Background 


Auth Type: An 8-bit value specifying the supported authentication 
type. 


The following enumerated values are supported: 


0 - Open System 
1 - WEP Shared Key 
MAC Mode: This field specifies whether the WIP should support the 


WLAN in Local or Split MAC mode. Note that the AC MUST NOT 
request a mode of operation that was not advertised by the WTP 
during the discovery process (see Section 4.6.43 in [RFC5415]). 
The following enumerated values are supported: 


0 - Local MAC: Service for the WLAN is to be provided in Local 
MAC mode. 
1 - Split MAC: Service for the WLAN is to be provided in Split 
MAC mode. 
Tunnel Mode: This field specifies the frame tunneling type to be 


used for 802.11 data frames from all stations associated with the 
WLAN. The AC MUST NOT request a mode of operation that was not 
advertised by the WIP during the discovery process (see Section 
4.6.42 in [RFC5415]). All IEEE 802.11 management frames MUST be 
tunneled using 802.11 Tunnel mode. The following enumerated 
values are supported: 


0 - Local Bridging: All user traffic is to be locally bridged. 
1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 
in 802.3 format (see Section 4.4.2 in [RFC5415]). Note that 


this option MUST NOT be selected with Split MAC mode. 


2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 
in 802.11 format. 


Suppress SSID: A boolean indicating whether the SSID is to be 
advertised by the WIP. A value of zero suppresses the SSID in the 
802.11 Beacon and Probe Response frames, while a value of one will 
cause the WIP to populate the field. 
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SSID: The SSID attribute is the service set identifier that will be 
advertised by the WIP for this WLAN. The SSID field contains any 
ASCII character and MUST NOT exceed 32 octets in length, as 
defined in [IEEE.802-11.2007]. 


6.2. IEEE 802.11 Antenna 


The IEEE 802.11 Antenna message element is communicated by the WIP to 
the AC to provide information on the antennas available. The AC MAY 
use this element to reconfigure the WIP’s antennas. The message 
element contains the following fields: 


0 1 2 3 
01234567890123456789012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID | Diversity | Combiner | Antenna Cnt | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Antenna Selection... 

+—-+-+-+-+-+-+-+-+ 


Type: 1025 for IEEE 802.11 Antenna 
Length: >= 5 
Radio ID: An 8-bit value representing the radio to configure, whose 


value is between one (1) and 31. 


Diversity: An 8-bit value specifying whether the antenna is to 
provide receiver diversity. The value of this field is the same 
as the IEEE 802.11 dotllDiversitySelectionRx MIB element, see 


[IEEE.802-11.2007]. The following enumerated values are 
supported: 

0 - Disabled 

1 - Enabled (may only be true if the antenna can be used as a 


receiving antenna) 


Combiner: An 8-bit value specifying the combiner selection. The 
following enumerated values are supported: 


1 - Sectorized (Left) 


2 - Sectorized (Right) 
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3 - Omni 
4 — Multiple Input/Multiple Output (MIMO) 

Antenna Count: An 8-bit value specifying the number of Antenna 
Selection fields. This value SHOULD be the same as the one found 


in the IEEE 802.11 dotilCurrentTxAntenna MIB element (see 
[IEEE.802-11.2007]). 


Antenna Selection: One 8-bit antenna configuration value per 
antenna in the WTP, containing up to 255 antennas. The following 
enumerated values are supported: 


1 - Internal Antenna 
2 - External Antenna 
6.3. IEEE 802.11 Assigned WIP BSSID 


The IEEE 802.11 Assigned WIP BSSID is only included by the WTP when 
the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 
Add WLAN message element. The BSSID value field of this message 
element contains the BSSID that has been assigned by the WTP, 
enabling the WIP to perform its own BSSID assignment. 


The WIP is free to assign the BSSIDs the way it sees fit, but it is 
highly recommended that the WIP assign the BSSID using the following 
algorithm: BSSID = {base BSSID} + WLAN ID. 


0 1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Radio ID | WLAN ID | BSSID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| BSSID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1026 for IEEE 802.11 Assigned WTP BSSID 
Length: 8 
Radio ID: An 8-bit value representing the radio, whose value is 


between one (1) and 31. 


WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 
MUST be between one (1) and 16. 
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BSSID: The BSSID assigned by the WTP for the WLAN created as a 
result of receiving an IEEE 802.11 Add WLAN. 


6.4. IEEE 802.11 Delete WLAN 


The IEEE 802.11 Delete WLAN message element is used to inform the WTP 
that a previously created WLAN is to be deleted, and contains the 
following fields: 


0 1 

0: S a S 78: 9-0 1 23.4 5 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID | WLAN ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1027 for IEEE 802.11 Delete WLAN 
Length: 2 
Radio ID: An 8-bit value representing the radio, whose value is 


between one (1) and 31. 


WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 
MUST be between one (1) and 16. 


6.5. IEEE 802.11 Direct Sequence Control 


The IEEE 802.11 Direct Sequence Control message element is a bi- 
directional element. When sent by the WTP, it contains the current 
state. When sent by the AC, the WTP MUST adhere to the values 
provided. This element is only used for IEEE 802.11b radios. The 
message element has the following fields. 


0 1 2 3 

On ES E 26> Fe ES A OI 28-4 3 46: E ES 20 he 3d A FB OO 

a a o ee ee ee 
| Radio ID | Reserved | Current Chan | Current CCA | 
FP ttt ata tartar a a o E E E 
| Energy Detect Threshold | 
FPP tata tata tata a o o o O 


Type: 1028 for IEEE 802.11 Direct Sequence Control 


Length: 8 


Calhoun, et al. Standards Track [Page 37] 


RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 


Radio ID: An 8-bit value representing the radio to configure, whose 
value is between one (1) and 31. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


Current Channel: This attribute contains the current operating 
frequency Channel of the Direct Sequence Spread Spectrum (DSSS) 
PHY. This value comes from the IEEE 802.11 dotllCurrentChannel 
MIB element (see [IEEE.802-11.2007]). 


Current CCA: The current Clear Channel Assessment (CCA) method in 
operation, whose value can be found in the IEEE 802.11 
dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]1). Valid 


values are: 


1 - energy detect only (edonly) 


2 - carrier sense only (csonly) 
4 - Carrier sense and energy detect (edandcs) 
8 - carrier sense with timer (cswithtimer) 


16 - high rate carrier sense and energy detect (hrcsanded) 


Energy Detect Threshold: The current Energy Detect Threshold being 
used by the DSSS PHY. The value can be found in the IEEE 802.11 
dot11EDThreshold MIB element (see [IEEE.802-11.2007]). 


6.6. IEEE 802.11 Information Element 


The IEEE 802.11 Information Element is used to communicate any IE 
defined in the IEEE 802.11 protocol. The data field contains the raw 
IE as it would be included within an IEEE 802.11 MAC management 
message. 


0 iL. 2 3 

0- 1-2 3:4 oe 7 8 9.0.1 223 4-5 6711890. 2.3) 45.6: 7 8: 9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID | WLAN ID |B|P| Reserved |Info Element... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Type: 1029 for IEEE 802.11 Information Element 
Length: >= 4 
Radio ID: An 8-bit value representing the radio, whose value is 


between one (1) and 31. 


WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 
MUST be between one (1) and 16. 


B: When set, the WTP is to include the Information Element in IEEE 
802.11 Beacons associated with the WLAN. 


Ps When set, the WTP is to include the Information Element in Probe 
Responses associated with the WLAN. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


Info Element: The IEEE 802.11 Information Element, which includes 
the type, length, and value field. 


6.7. IEEE 802.11 MAC Operation 


The IEEE 802.11 MAC Operation message element is sent by the AC to 
set the IEEE 802.11 MAC parameters on the WIP, and contains the 
following fields. 


0 1 2 3 
0.1.2.3456789012345678090123456708 9 041 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID | Reserved | RTS Threshold 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Short Retry | Long Retry | Fragmentation Threshold | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Tx MSDU Lifetime | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Rx MSDU Lifetime | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type: 1030 for IEEE 802.11 MAC Operation 

Length: 16 
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Radio ID: An 8-bit value representing the radio to configure, whose 
value is between one (1) and 31. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


RTS Threshold: This attribute indicates the number of octets in an 
MAC Protocol Data Unit (MPDU), below which a Request To Send/Clear 
To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/CTS 
handshake MUST be performed at the beginning of any frame exchange 
sequence where the MPDU is of type Data or Management, the MPDU 
has an individual address in the Addressl field, and the length of 
the MPDU is greater than this threshold. Setting this attribute 
to be larger than the maximum MSDU size MUST have the effect of 
turning off the RTS/CTS handshake for frames of Data or Management 
type transmitted by this STA. Setting this attribute to zero MUST 
have the effect of turning on the RTS/CTS handshake for all frames 
of Data or Management type transmitted by this STA. The default 
value of this attribute MUST be 2347. The value of this field 
comes from the IEEE 802.11 dot11RTSThreshold MIB element, (see 
[IEEE.802-11.2007]). 


Short Retry: This attribute indicates the maximum number of 
transmission attempts of a frame, the length of which is less than 
or equal to RTSThreshold, that MUST be made before a failure 
condition is indicated. The default value of this attribute MUST 
be 7. The value of this field comes from the IEEE 802.11 
dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]). 


Long Retry: This attribute indicates the maximum number of 
transmission attempts of a frame, the length of which is greater 
than dot11RTSThreshold, that MUST be made before a failure 
condition is indicated. The default value of this attribute MUST 
be 4. The value of this field comes from the IEEE 802.11 
dot1l1lLongRetryLimit MIB element, (see [IEEE.802-11.2007]). 


Fragmentation Threshold: This attribute specifies the current 
maximum size, in octets, of the MPDU that MAY be delivered to the 
PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments 
if its size exceeds the value of this attribute after adding MAC 
headers and trailers. An MSDU or MAC Management Protocol Data 
Unit (MMPDU) MUST be fragmented when the resulting frame has an 
individual address in the Addressl field, and the length of the 
frame is larger than this threshold. The default value for this 
attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 
attached PHY and MUST never exceed the lesser of 2346 or the 
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aMPDUMaxLength of the attached PHY. The value of this attribute 
MUST never be less than 256. The value of this field comes from 
the IEEE 802.11 dotllFragmentationThreshold MIB element, (see 
[IEEE.802-11.2007]). 


Tx MSDU Lifetime: This attribute specifies the elapsed time in Time 
Units (TUs), after the initial transmission of an MSDU, after 
which further attempts to transmit the MSDU MUST be terminated. 
The default value of this attribute MUST be 512. The value of 
this field comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime 
MIB element, (see [IEEE.802-11.2007]). 


Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 
after the initial reception of a fragmented MMPDU or MSDU, after 
which further attempts to reassemble the MMPDU or MSDU MUST be 
terminated. The default value MUST be 512. The value of this 
field comes from the IEEE 802.11 dotllMaxReceiveLifetime MIB 
element, (see [IEEE.802-11.2007]). 


6.8. IEEE 802.11 MIC Countermeasures 


The IEEE 802.11 MIC Countermeasures message element is sent by the 
WIP to the AC to indicate the occurrence of a MIC failure. For more 
information on MIC failure events, see the 
dot11RSNATKIPCounterMeasuresInvoked MIB element definition in 
[IEEE.802-11.2007]. 


0 1 2 3 

01234567890123 456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID | WLAN ID | MAC Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| MAC Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1031 for IEEE 802.11 MIC Countermeasures 
Length: 8 
Radio ID: The Radio Identifier, whose value is between one (1) and 


31, typically refers to some interface index on the WTP. 


WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 
on which the MIC failure occurred. The value MUST be between one 
(1) and 16. 
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MAC Address: The MAC Address of the station that caused the MIC 
failure. 


6.9. IEEE 802.11 Multi-Domain Capability 


The IEEE 802.11 Multi-Domain Capability message element is used by 
the AC to inform the WIP of regulatory limits. The AC will transmit 
one message element per frequency band to indicate the regulatory 
constraints in that domain. The message element contains the 
following fields. 


0 

o 1 
+++ 
| Radio ID Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Number of Channels 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
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Type: 1032 for IEEE 802.11 Multi-Domain Capability 
Length: 8 


Radio ID: An 8-bit value representing the radio to configure, whose 
value is between one (1) and 31. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


First Channel #: This attribute indicates the value of the lowest 
channel number in the sub-band for the associated domain country 
string. The value of this field comes from the IEEE 802.11 
dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). 


Number of Channels: This attribute indicates the value of the total 
number of channels allowed in the sub-band for the associated 
domain country string (see Section 6.23). The value of this field 
comes from the IEEE 802.11 dot1llNumberofChannels MIB element (see 
[IEEE.802-11.2007]). 


Max Tx Power Level: This attribute indicates the maximum transmit 
power, in dBm, allowed in the sub-band for the associated domain 
country string (see Section 6.23). The value of this field comes 


from the IEEE 802.11 dotl11MaximumTransmitPowerLevel MIB element 
(see [IEEE.802-11.2007]). 
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6.10. IEEE 802.11 OFDM Control 


The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) 
Control message element is a bi-directional element. When sent by 
the WTP, it contains the current state. When sent by the AC, the WIP 
MUST adhere to the received values. This message element is only 
used for 802.1la radios and contains the following fields: 


0 1 2 3 
01:23:45 67-38 9 01 23:4 5.6 7890 12-3 4.5 6 7-38 9:0 1 
Fatt tata tata t a a o o o O 
| Radio ID | Reserved | Current Chan | Band Support | 
Fatt tata tartar tartar a o MHH 
| TI Threshold | 
FPP tata tata tata o o o E O 


Type: 1033 for IEEE 802.11 OFDM Control 
Length: 8 
Radio ID: An 8-bit value representing the radio to configure, whose 


value is between one (1) and 31. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


Current Channel: This attribute contains the current operating 
frequency channel of the OFDM PHY. The value of this field comes 
from the IEEE 802.11 dotl1lCurrentFrequency MIB element (see 
[IEEE.802-11.2007]). 


Band Supported: The capability of the OFDM PHY implementation to 
operate in the three Unlicensed National Information 
Infrastructure (U-NII) bands. The value of this field comes from 
the IEEE 802.11 dotllFrequencyBandsSupported MIB element (see 
[IEEE.802-11.2007]), coded as a bit field, whose values are: 


Bit 0 - capable of operating in the 5.15-5.25 GHz band 
Bit 1 - capable of operating in the 5.25-5.35 GHz band 
Bit 2 - capable of operating in the 5.725-5.825 GHz band 
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Bit 3 - capable of operating in the 5.47-5.725 GHz band 
Bit 4 - capable of operating in the lower Japanese 5.25 GHz band 
Bit 5 - capable of operating in the 5.03-5.091 GHz band 
Bit 6 - capable of operating in the 4.94-4.99 GHz band 


For example, for an implementation capable of operating in the 
5.15-5.35 GHz bands, this attribute would take the value 3. 


TI Threshold: The threshold being used to detect a busy medium 
(frequency). CCA MUST report a busy medium upon detecting the 
RSSI above this threshold. The value of this field comes from the 
IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]). 


6.11. IEEE 802.11 Rate Set 


The rate set message element value is sent by the AC and contains the 
supported operational rates. It contains the following fields. 


1 
901 
= +-+-4+- 


| Radio I 
+—+-+-+-+-4+-4+-4+- 


+ © 
Xe) 


1 
-+-+-+-+-+-+-+- + 


l 
+ 
l 
4 


E 
PE 
A a A 
Type: 1034 for IEEE 802.11 Rate Set 
Length: >= 3 


Radio ID: An 8-bit value representing the radio to configure, whose 
value is between one (1) and 31. 


Rate Set: The AC generates the Rate Set that the WTP is to include 
in its Beacon and Probe messages. The length of this field is 
between 2 and 8 bytes. The value of this field comes from the 


IEEE 802.11 dotllO0perationalRateSet MIB element (see 
[IEEE.802-11.2007]). 


6.12. IEEE 802.11 RSNA Error Report From Station 


The IEEE 802.11 RSN Error Report From Station message element is used 
by a WIP to send RSN error reports to the AC. The WTP does not need 
to transmit any reports that do not include any failures. The fields 
from this message element come from the IEEE 802.11 
Dot11RSNAStatsEntry table, see [IEEE.802-11.2007]. 
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0 1 2 3 
0123456789012345678°9012345678<90 21 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Client MAC Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Client MAC Address | BSSID 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| BSSID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID WLAN ID Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TKIP ICV Errors | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TKIP Local MIC Failures | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TKIP Remote MIC Failures | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CCMP Replays | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CCMP Decrypt Errors | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TKIP Replays | 
4-+—4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4-4-4-4-4-4-4-4-4-4 


Type: 1035 for IEEE 802.11 RSNA Error Report From Station 
Length: 40 

Client MAC Address: The Client MAC Address of the station. 
BSSID: The BSSID on which the failures are being reported. 


Radio ID: The Radio Identifier, whose value is between one (1) and 
31, typically refers to some interface index on the WTP. 


WLAN ID: The WLAN ID on which the RSNA failures are being reported. 
The value MUST be between one (1) and 16. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 
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TKIP ICV Errors: A 32-bit value representing the number of Temporal 
Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) 
ICV errors encountered when decrypting packets from the station. 
The value of this field comes from the IEEE 802.11 
dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]). 


TKIP Local MIC Failures: A 32-bit value representing the number of 
MIC failures encountered when checking the integrity of packets 
received from the station. The value of this field comes from the 
IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 
[IEEE.802-11.2007]). 


TKIP Remote MIC Failures: A 32-bit value representing the number of 
MIC failures reported by the station encountered (possibly via the 
EAPOL-Key frame). The value of this field comes from the IEEE 


802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see 
[IEEE.802-11.2007]). 


CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 
discarded by the replay detection mechanism. The value of this 
field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 
(see [IEEE.802-11.2007]). 


CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 
MDPUs discarded by the decryption algorithm. The value of this 
field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 
element (see [IEEE.802-11.2007]). 


TKIP Replays: A 32-bit value representing the number of TKIP 
Replays detected in frames received from the station. The value 
of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 
MIB element (see [IEEE.802-11.2007]). 


6.13. IEEE 802.11 Station 
The IEEE 802.11 Station message element accompanies the Add Station 
message element, and is used to deliver IEEE 802.11 station policy 


from the AC to the WTP. 


The latest IEEE 802.11 Station message element overrides any 
previously received message elements. 


If the QoS field is set, the WIP MUST observe and provide policing of 


the 802.11e priority tag to ensure that it does not exceed the value 
provided by the AC. 
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0 1 2 3 
0123456789012345678°9012345678<90 1 
+-+-+-+-+-+-+-+-+-+-+- hh hh hh ho o +++ 

| Radio ID | Association ID | Flags 

+-+-+-+-+-+-+-+-+-+-+- +++ 
| MAC Address | 
+-+-+-+-+-+-+-+-+-+-+-+ +H 


| MAC Address | Capabilities 
E ooo oo ++ 
| WLAN ID | Supported Rates| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1036 for IEEE 802.11 Station 
Length: >= 14 
Radio ID: An 8-bit value representing the radio, whose value is 


between one (1) and 31. 


Association ID: A 16-bit value specifying the IEEE 802.11 
Association Identifier. 


Flags: All implementations complying with this protocol MUST set to 
zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


MAC Address: The station’s MAC Address 


Capabilities: A 16-bit field containing the IEEE 802.11 
Capabilities Information Field to use with the station. 


WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 
MUST be between one (1) and 16. 


Supported Rates: The variable-length field containing the supported 
rates to be used with the station, as found in the IEEE 802.11 
dot11l0OperationalRateSet MIB element (see [IEEE.802-11.2007]). 

This field MUST NOT exceed 126 octets and specifies the set of 
data rates at which the station may transmit data, where each 
octet represents a data rate. 


6.14. IEEE 802.11 Station QoS Profile 


The IEEE 802.11 Station QoS Profile message element contains the 

maximum IEEE 802.11le priority tag that may be used by the station. 
Any packet received that exceeds the value encoded in this message 
element MUST be tagged using the maximum value permitted by to the 
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user. The priority tag MUST be between zero (0) and seven (7). This 
message element MUST NOT be present without the IEEE 802.11 Station 
(see Section 6.13) message element. 


0 1 2 3 
001.234.906: 1.8 59001, 2-3 45 6-7 89 00:10:23 456-7890 1 
dh + hh q + hd + + + + + ++ + +++ + ++ +++ +++ += 
| MAC Address | 
dh + hh q o hd + + + + + ++ ++ +++ + +++ ++ +++ 
| MAC Address | Reserved |8021p| 
d+ Ph q + hd + + + + + ++ + + +++ ++ ++ + +++ += 


Type: 1037 for IEEE 802.11 Station QoS Profile 

Length: 8 

MAC Address: The station’s MAC Address 

Reserved: All implementations complying with this protocol MUST set 


to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


8021p: The maximum 802.1p priority value that the WIP will allow in 
the Traffic Identifier (TID) field in the extended 802.1le QoS 
Data header. 


6.15. IEEE 802.11 Station Session Key 


The IEEE 802.11 Station Session Key message element is sent by the AC 
to provision encryption keys, or to configure an access policy, on 
the WTP. This message element MUST NOT be present without the IEEE 
802.11 Station (see Section 6.13) message element, and MUST NOT be 
sent if the WIP had not specifically advertised support for the 
requested encryption scheme, through the WIP Descriptor Message 
Element’s Encryption Capabilities field (see Section 8.1). 


When the Key field is non-zero in length, the RSN Information Element 
MUST be sent along with the IEEE 802.11 Station Session Key in order 
to instruct the WIP on the usage of the Key field. The WIP MUST 
observe the Authentication and Key Management (AKM) field of the RSN 
Information Element in order to identify the authentication protocol 
to be enforced with the station. 


If cryptographic services are provided at the WTP, the WTP MUST 
observe the algorithm dictated in the Pairwise Cipher Suite field of 
the RSN Information Element sent by the AC. The RSN Information 
Element included here is the one sent by the AC in the third message 
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applied to provide encryption and decryption services with the 
The RSN Information Element is used to communicate any 


station. 


supported algorithm, including WEP, TKIP, and AES-CCMP. 


of static WEP keys, the RSN Information Element is still used to 


indicate the cryptographic algorithm even though no key exchange 


occurred. 


which specifies which cipher is to be 


In the case 


If the IEEE 802.11 Station Session Key message element’s ’AKM-Only’ 


bit is set, 
part of the Authentication and Key Management 
Note that AKM-Only MAY be set while an encryption key is in force, 
requiring that the AKM packets be encrypted. 
successfully completed authentication via the AKM, the AC MUST send a 
new Add Station message element to remove the AKM-Only restriction, 
and optionally push the session key down to the WTP. 


0 


the WTP MUST drop all IEEE 802.11 packets that are not 
(AKM), such as EAP. 


1 


Once the station has 


2 


3 


01234567890123456789012345678901 
E 


+++ 


+++ 


+++ 


+++ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


MAC Address 
—+-+-4-4+-4+-+4+-4+-4+-4+-4+-4+-+4+-4+-4-4- 
MAC Address |a|c| 
—+-4+-4-4+-4+-4+-4+-4+-4+-4+-4-4+-4+-4-4- 

Pairwise TSC 
—+-4+-4-4+-4+-4+-4+-4+-+4+-4+-4+-4+-4+-4-4- 
Pairwise TSC 
—+-+-4-4+-4+-4+-4+-4+-4+-4+-4-+4+-4+-4-4- 

Pairwise RSC 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


Key.. 


+-+-+-+-+-+-+-+- 


+ 


+ 


+ 


+ 


+ 


+ 


-+-+-+-+-+-+-+-+-+-+-+-— 


—+-+-4+-+-+-+-4+- 
Flags 
—+-+-4+-4+-+-+-4+- 


—+-+-4+-+-4+-4+-4- 
Pairwise RSC 


-+-+-+-+-+-+-+- 


-+-+-+-+-+-+-+- 


Type: 1038 for IEEE 802.11 Station Session Key 


MAC Address: 


Flags: 


25 


The station’s MAC Address 


+-+- 


+ 


+ 


+ 


+ 


zero any bits that are reserved in the version of the protocol 


supported by that implementation. 


not defined for the version of the protocol they support. 
following bits are defined: 
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=+- 


=+- 


=+- 


=+- 


=+- 


Receivers MUST ignore all bits 
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All implementations complying with this protocol MUST set to 
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6. 


A: The 1-bit AKM-Only field is set by the AC to inform the WIP 


that is MUST NOT accept any 802.11 Data Frames other than AKM 
frames. This is the equivalent of the WIP’s IEEE 802.1X port 
for the station to be in the closed state. When set, the WTP 
MUST drop any non-IEEE 802.1X packets it receives from the 
station. 


Es The 1-bit field is set by the AC to inform the WIP that 
encryption services will be provided by the AC. When set, 
the WTP SHOULD police frames received from stations to ensure 
that they are properly encrypted as specified in the RSN 
Information Element, but does not need to take specific 
cryptographic action on the frame. Similarly, for 
transmitted frames, the WIP only needs to forward already 
encrypted frames. Since packets received by the WTP will be 
encrypted, the WIP cannot modify the contents of the packets, 
including modifying the DSCP markings of the encapsulated 
packet. In this case, this function would be the 
responsibility of the AC. 


Pairwise TSC: The 6-byte Transmit Sequence Counter (TSC) field to 


use for unicast packets transmitted to the station. 


Pairwise RSC: The 6-byte Receive Sequence Counter (RSC) to use for 


Key: 


16. 


unicast packets received from the station. 


The pairwise key the WIP is to use when encrypting traffic to/ 
from the station. The format of the keys differs based on the 
crypto algorithm used. For unicast WEP keys, the Key field 
consists of the actual unicast encryption key (note, this is used 
when WEP is used in conjunction with 802.1X, and therefore a 
unicast encryption key exists). When used with CCMP, the Key 
field includes the 128-bit Temporal Key. When used with TKIP, the 
Key field includes the 256-bit Temporal Key (which consists of a 
128-bit key used as input for TKIP key mixing, and two 64-bit keys 
used for Michael). 


IEEE 802.11 Statistics 


The IEEE 802.11 Statistics message element is sent by the WTP to 
transmit its current statistics, and it contains the following 
fields. All of the fields in this message element are set to zero 
upon WTP initialization. The fields will roll over when they reach 
their maximum value of 4294967295. Due to the nature of each counter 
representing different data points, the rollover event will vary 
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greatly across each field. Applications or human operators using 
these counters need to be aware of the minimal possible times between 
rollover events in order to make sure that no consecutive rollover 
events are missed. 


0 1 2 3 
0123456789012345678°9012345678<9021 
YH A A A A tata O O tata tate A O A O A O A tata O A O A A o + H 
| Radio ID | Reserved | 
ee 
| Tx Fragment Count | 
Potato A tata O O tata A O A O A O A O A O A O tate A O A O A + 4 
| Multicast Tx Count | 
YH A A O A O O O O A O A O A O A O A O A O O O A O A O o + + 4 
| Failed Count | 
Foto totaototo toto tata toto tata taitat tata tat ai tata tata tatetatetitetat 
| Retry Count | 
YH A A A A toto O tate tate tate A O A O A tata O tate A A + H 

| Multiple Retry Count 

Potato A A A O O tata A O tate tata A O A O O O tata tatetatetitetet 
| Frame Duplicate Count | 
E 
| RTS Success Count | 
Potato A O ota O tata A O tate toto A O A O A O O tate A O A O A + 
| RTS Failure Count | 
ot ato A toto O tata A O tate A O A O A O A O tate tate A O + + + 
| ACK Failure Count | 
Foto A A O O toto O O tate A O tito A O A O A O O O A O A O A + 
| Rx Fragment Count | 
YH A A O A tata O O tate tate tite A O A O A O tata A O A O + H 
| Multicast RX Count 
ee 
| FCS Error Count | 
YH A A A A tata O O tated tata A O A O O tata tata A O A A + + 
| Tx Frame Count | 
Foto A A A A O O tata A O tate A O A O A O A tata tata A O A O A + H 
| Decryption Errors | 
YH A A A A O tata A O tata A O A O A tat O tata A O A o o + + 
| Discarded QoS Fragment Count 

Potato A A A O O tata A O A O A O A O A O A tata tate tate A + + + + 
| Associated Station Count 

Hot A A O A toto O O tata A O A O A O A O A O O O A O A O A + + 
| QoS CF Polls Received Count 

Potato A tata O O tata A O toto tito A O A O A O tate A O A O A + 
| QoS CF Polls Unused Count 

YH A A A A O O O O A O A O A O A O A O O O O O A O A O + + 
| QoS CF Polls Unusable Count 

YH A A O A toto O O tata A O A O AO O A O A O tate A O A O A + + 
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Type: 1039 for IEEE 802.11 Statistics 
Length: 80 
Radio ID: An 8-bit value representing the radio, whose value is 


between one (1) and 31. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


Tx Fragment Count: A 32-bit value representing the number of 
fragmented frames transmitted. The value of this field comes from 
the IEEE 802.11 dotllTransmittedFragmentCount MIB element (see 
[IEEE.802-11.2007]). 


Multicast Tx Count: A 32-bit value representing the number of 
multicast frames transmitted. The value of this field comes from 
the IEEE 802.11 dotl1MulticastTransmittedFrameCount MIB element 
(see [IEEE.802-11.2007]). 


Failed Count: A 32-bit value representing the transmit excessive 
retries. The value of this field comes from the IEEE 802.11 
dotllFailedCount MIB element (see [IEEE.802-11.2007]). 


Retry Count: A 32-bit value representing the number of transmit 
retries. The value of this field comes from the IEEE 802.11 
dot11RetryCount MIB element (see [IEEE.802-11.2007]). 


Multiple Retry Count: A 32-bit value representing the number of 
transmits that required more than one retry. The value of this 
field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 
element (see [IEEE.802-11.2007]). 


Frame Duplicate Count: A 32-bit value representing the duplicate 
frames received. The value of this field comes from the IEEE 
802.11 dotllFrameDuplicateCount MIB element (see 
[IEEE.802-11.2007]). 


RTS Success Count: A 32-bit value representing the number of 
successfully transmitted Ready To Send (RTS). The value of this 
field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 
(see [IEEE.802-11.2007]). 
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RTS Failure Count: A 32-bit value representing the failed 
transmitted RTS. The value of this field comes from the IEEE 
802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]). 


ACK Failure Count: A 32-bit value representing the number of failed 
acknowledgements. The value of this field comes from the IEEE 
802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]). 


Rx Fragment Count: A 32-bit value representing the number of 
fragmented frames received. The value of this field comes from 
the IEEE 802.11 dotllReceivedFragmentCount MIB element (see 
[IEEE.802-11.2007]). 


Multicast RX Count: A 32-bit value representing the number of 
multicast frames received. The value of this field comes from the 
IEEE 802.11 dot1l1lMulticastReceivedFrameCount MIB element (see 
[IEEE.802-11.2007]). 


FCS Error Count: A 32-bit value representing the number of FCS 
failures. The value of this field comes from the IEEE 802.11 
dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]). 


Decryption Errors: A 32-bit value representing the number of 
Decryption errors that occurred on the WIP. Note that this field 
is only valid in cases where the WTP provides encryption/ 
decryption services. The value of this field comes from the IEEE 
802.11 dot11WEPUndecryptableCount MIB element (see 
[IEEE.802-11.2007]). 


Discarded QoS Fragment Count: A 32-bit value representing the 
number of discarded QoS fragments received. The value of this 
field comes from the IEEE 802.11 dot1100SDiscardedFragmentCount 
MIB element (see [IEEE.802-11.2007]). 


Associated Station Count: A 32-bit value representing the number of 
number of associated stations. The value of this field comes from 
the IEEE 802.11 dot1lAssociatedStationCount MIB element (see 
[IEEE.802-11.2007]). 


QoS CF Polls Received Count: A 32-bit value representing the number 
of (+)CF-Polls received. The value of this field comes from the 
IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see 
[IEEE.802-11.2007]). 


QoS CF Polls Unused Count: A 32-bit value representing the number 
of (+)CF-Polls that have been received, but not used. The value 
of this field comes from the IEEE 802.11 
dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]). 
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6. 


6. 


QoS CF Polls Unusable Count: A 32-bit value representing the number 
of (+)CF-Polls that have been received, but could not be used due 
to the Transmission Opportunity (TXOP) size being smaller than the 
time that is required for one frame exchange sequence. The value 
of this field comes from the IEEE 802.11 
dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]). 


17. IEEE 802.11 Supported Rates 


The IEEE 802.11 Supported Rates message element is sent by the WTP to 
indicate the rates that it supports, and contains the following 
fields. 


0 al 2 3 

On 2h 3. 4 o S 8 OO DE ES 64 5:06: 518.090: 2 3-4 5 6. 8 OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++t 
| Radio ID | Supported Rates... 
foto A AA O O toto ta A A A A O O to O A A A A A O A + + 


Type: 1040 for IEEE 802.11 Supported Rates 
Length: >= 3 
Radio ID: An 8-bit value representing the radio, whose value is 


between one (1) and 31. 


Supported Rates: The WIP includes the Supported Rates that its 
hardware supports. The format is identical to the Rate Set 
message element and is between 2 and 8 bytes in length. 


18% IEEE 802.11 Tx Power 


The IEEE 802.11 Tx Power message element value is bi-directional. 
When sent by the WIP, it contains the current power level of the 
radio in question. When sent by the AC, it contains the power level 
to which the WTP MUST adhere. 


0 1 2 3 
OL23 49 67 89 04.23 4-5 678 9:01 2°3:4.5°6.7 8 9-0 2 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Radio ID | Reserved | Current Tx Power 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1041 for IEEE 802.11 Tx Power 
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Length: 4 


Radio ID: An 8-bit value representing the radio to configure, whose 
value is between one (1) and 31. 


Reserved: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all bits 
not defined for the version of the protocol they support. 


Current Tx Power: This attribute contains the current transmit 
output power in mW, as described in the dotllCurrentTxPowerLevel 
MIB variable, see [IEEE.802-11.2007]. 


6.19. IEEE 802.11 Tx Power Level 


The IEEE 802.11 Tx Power Level message element is sent by the WIP and 
contains the different power levels supported. The values found in 
this message element are found in the IEEE 802.11 
Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007]. 


The value field contains the following: 


0 1 2 3 
0.1023 4°35 6°78 90 1:23 3.678. 90:01:23 45 678 90 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Radio ID | Num Levels | Power Level [n] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1042 for IEEE 802.11 Tx Power Level 
Length: >= 4 
Radio ID: An 8-bit value representing the radio to configure, whose 


value is between one (1) and 31. 


Num Levels: The number of power level attributes. The value of 
this field comes from the IEEE 802.11 
dot1liNumberSupportedPowerLevels MIB element (see 
[IEEE.802-11.2007]). 


Power Level: Each power level field contains a supported power 
level, in mW. The value of this field comes from the 
corresponding IEEE 802.11 dot11TxPowerlLevel[n] MIB element, see 
[IEEE.802-11.2007]. 


Calhoun, et al. Standards Track [Page 55] 


RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 


6.20. IEEE 802.11 Update Station QoS 


The IEEE 802.11 Update Station QoS message element is used to change 
the Quality of Service policy on the WIP for a given station. The 
QoS tags included in this message element are to be applied to 
packets received at the WIP from the station indicated through the 
MAC Address field. This message element overrides the default values 
provided through the IEEE 802.11 WIP Quality of Service message 
element (see Section 6.22). Any tagging performed by the WIP MUST be 
directly applied to the packets received from the station, as well as 
the CAPWAP tunnel, if the packets are tunneled to the AC. See 
Section 2.6 for more information. 


0 1 2 3 
OM L243" 49: 46 PB DO A 253 “ae BO 23 A a 02 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Radio ID | MAC Address | 
HA AAA A A A O A O O AO A A A O O O O A A A o A A ++ 
| MAC Address | QoS Sub-Element... 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Type: 1043 for IEEE 802.11 Update Station QoS 
Length: 8 
Radio ID: The Radio Identifier, whose value is between one (1) and 


31, typically refers to some interface index on the WTP. 
MAC Address: The station’s MAC Address. 


QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 
element contains four QoS sub-elements, one for every QoS profile. 
The order of the QoS profiles are Voice, Video, Best Effort, and 
Background. 


0 1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved|8021p|RSV| DSCP Tag | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Reserved: All implementations complying with this protocol MUST 
set to zero any bits that are reserved in the version of the 
protocol supported by that implementation. Receivers MUST 
ignore all bits not defined for the version of the protocol 
they support. 
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8021p: The 3-bit 802.1p priority value to use if packets are to 
be IEEE 802.1p tagged. This field is used only if the 'P” bit 
in the WTP Quality of Service message element was set; 
otherwise, its contents MUST be ignored. 


RSV: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the 
protocol supported by that implementation. Receivers MUST 
ignore all bits not defined for the version of the protocol 
they support. 


DSCP Tag: The 6-bit DSCP label to use if packets are eligible to 
be DSCP tagged, specifically an IPv4 or IPv6 packet (see 
[RFC2474]). This field is used only if the ’D’ bit in the WTP 


Quality of Service message element was set; otherwise, its 
contents MUST be ignored. 


6.21. IEEE 802.11 Update WLAN 


The IEEE 802.11 Update WLAN message element is used by the AC to 
define a wireless LAN on the WIP. The inclusion of this message 
element MUST also include the IEEE 802.11 Information Element message 
element, containing the following 802.11 IEs: 


Power Constraint information element 
WPA information element [WPA] 
RSN information element 


Enhanced Distributed Channel Access (EDCA) Parameter Set information 
element 


QoS Capability information element 
WMM information element [WMM] 


These IEEE 802.11 Information Elements are stored by the WTP and 
included in any Probe Responses and Beacons generated, as specified 
in the IEEE 802.11 standard [IEEE.802-11.2007]. 


If cryptographic services are provided at the WTP, the WTP MUST 
observe the algorithm dictated in the Group Cipher Suite field of the 
RSN Information Element sent by the AC. The RSN Information Element 
is used to communicate any supported algorithm, including WEP, TKIP, 
and AES-CCMP. In the case of static WEP keys, the RSN Information 
Element is still used to indicate the cryptographic algorithm even 
though no key exchange occurred. 
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The message element uses the following format: 


0 1 2 3 
OL 2°3) 4: 9-6 708: 9-002. 22°34 5: 6 18.9 0 273) 4 26.7. Be 90 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Radio ID | WLAN 1D | Capability | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Key Index | Key Status | Key Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Key... | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type: 1044 for IEEE 802.11 Update WLAN 
Length: >= 8 
Radio ID: An 8-bit value representing the radio, whose value is 
between one (1) and 31. 
WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 


MUST be between one (1) and 16. 


Capability: A 16-bit value containing the Capability information 
field to be advertised by the WTP in the Probe Request and Beacon 
frames. Each bit of the Capability field represents a different 
WTP capability, which are described in detail in 
[IEEE.802-11.2007]. The format of the field is: 


0 1 
01234567890123 45 


E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 
to 1 
I (IBSS): The AC MUST set the Independent Basic Service Set 


(IBSS) subfield to 0. 

C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 
Pollable) subfield based on the table found in 
[IEEE.802-11.2007]. 


F (CF-Poll Request): The AC sets the CF-Poll Request subfield 
based on the table found in [IEEE.802-11.2007]. 
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(Privacy): The AC sets the Privacy subfield based on the 
confidentiality requirements of the WLAN, as defined in 
[IEEE.802-11.2007]. 


(Short Preamble): The AC sets the Short Preamble subfield 
based on whether the use of short preambles are permitted on the 
WLAN, as defined in [IEEE.802-11.2007]. 


(PBCC): The AC sets the Packet Binary Convolutional Code 
(PBCC) modulation option subfield based on whether the use of 
PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007]. 


(Channel Agility): The AC sets the Channel Agility subfield 
based on whether the WIP is capable of supporting the High Rate 
Direct Sequence Spread Spectrum (HR/DSSS), as defined in 
[IEEE.802-11.2007]. 


(Spectrum Management): The AC sets the Spectrum Management 
subfield according to the value of the 
dot11SpectrumManagementRequired MIB variable, as defined in 
[IEEE.802-11.2007]. 


(QOS): The AC sets the Quality of Service (QoS) subfield based 
on the table found in [IEEE.802-11.2007]. 


(Short Slot Time): The AC sets the Short Slot Time subfield 
according to the value of the WTP’s currently used slot time 
value, as defined in [IEEE.802-11.2007]. 


(APSD): The AC sets the APSD subfield according to the value 
of the dot11APSDOptionImplemented Management Information Base 
(MIB) variable, as defined in [IEEE.802-11.2007]. 


(Reserved): The AC sets the Reserved subfield to zero, as 
defined in [IEEE.802-11.2007]. 


(DSSS-OFDM) : The AC sets the DSSS-OFDM subfield to indicate 
the use of Direct Sequence Spread Spectrum with Orthogonal 
Frequency Division Multiplexing (DSSS-OFDM), as defined in 
[IEEE.802-11.2007]. 


(Delayed Block ACK): The AC sets the Delayed Block ACK 
subfield according to the value of the 
dot11DelayedBlockAckOptionImplemented MIB variable, as defined 
in [IEEE.802-11.2007]. 
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L (Immediate Block ACK): The AC sets the Delayed Block ACK 
subfield according to the value of the 
dot11ImmediateBlockAckOptionImplemented MIB variable, as defined 
in [IEEE.802-11.2007]. 


Key-Index: The Key-Index associated with the key. 


Key Status: A l-byte value that specifies the state and usage of 
the key that has been included. The following values describe the 
key usage and its status: 


0 - A value of zero, with the inclusion of the RSN Information 
Element means that the WLAN uses per-station encryption keys, 
and therefore the key in the 'Key” field is only used for 
multicast traffic. 


1 - When set to one, the WLAN employs a shared WEP key, also 
known as a static WEP key, and uses the encryption key for 
both unicast and multicast traffic for all stations. 


2 - The value of 2 indicates that the AC will begin rekeying the 
GTK with the STA’s in the BSS. It is only valid when IEEE 
802.11 is enabled as the security policy for the BSS. 


3 - The value of 3 indicates that the AC has completed rekeying 
the GTK and broadcast packets no longer need to be duplicated 
and transmitted with both GTK’s. 


Key Length: A 16-bit value representing the length of the Key 
field. 
Key: A Session Key, whose length is known via the Key Length field, 


used to provide data privacy. For static WEP keys, which is true 
when the 'Key Status’ bit is set to one, this key is used for both 
unicast and multicast traffic. For encryption schemes that employ 
a separate encryption key for unicast and multicast traffic, the 
key included here only applies to multicast data, and the cipher 
suite is specified in an accompanied RSN Information Element. In 
these scenarios, the key, and cipher information, is communicated 
via the Add Station message element, see Section 4.6.8 in 
[RFC5415]. When used with WEP, the Key field includes the 
broadcast key. When used with CCMP, the Key field includes the 
128-bit Group Temporal Key. When used with TKIP, the Key field 
includes the 256-bit Group Temporal Key (which consists of a 128- 
bit key used as input for TKIP key mixing, and two 64-bit keys 
used for Michael). 
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6.22. IEEE 802.11 WTP Quality of Service 


The IEEE 802.11 WIP Quality of Service message element value is sent 
by the AC to the WTP to communicate Quality of Service configuration 
information. The QoS tags included in this message element are the 
default QoS values to be applied to packets received by the WIP from 
stations on a particular radio. Any tagging performed by the WTP 
MUST be directly applied to the packets received from the station, as 
well as the CAPWAP tunnel, if the packets are tunneled to the AC. 

See Section 2.6 for more information. 


0 1 2 3 

01-22-3456 728 O01 2-3 4-3 6.7 8:09:01 -2:-3.4-5-:6 7 08:09 01 
dos O O O O O O pipet O O hs o o o o o 
| Radio ID |Tagging Policy | QoS Sub-Element 
A A NN A HHHH 


Type: 1045 for IEEE 802.11 WIP Quality of Service 
Length: 34 
Radio ID: The Radio Identifier, whose value is between one (1) and 


31, typically refers to some interface index on the WTP. 


Tagging Policy: A bit field indicating how the WTP is to mark 
packets for QoS purposes. The required WIP behavior is defined in 
Section 2.6.1. The field has the following format: 


01234567 


Rsvd: A set of reserved bits for future use. All implementations 
complying with this protocol MUST set to zero any bits that are 
reserved in the version of the protocol supported by that 
implementation. Receivers MUST ignore all bits not defined for 
the version of the protocol they support. 


Ps When set, the WIP is to employ the 802.1p QoS mechanism (see 
Section 2.6.1.1), and the WTP is to use the ’Q’ bit. 


O: When the 'P” bit is set, the ’Q’ bit is used by the AC to 
communicate to the WIP how 802.1p QoS is to be enforced. 
Details on the behavior of the ’Q’ bit are specified in 
Section 2.6.1.1. 
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D: When set, the WIP is to employ the DSCP QoS mechanism (see 
Section 2.6.1.2), and the WTP is to use the '0' and 'I'” bits. 


O: When the 'D” bit is set, the ’0’ bit is used by the AC to 
communicate to the WTP how DSCP QoS is to be enforced on the 
outer (tunneled) header. Details on the behavior of the ’0’ 
bit are specified in Section 2.6.1.2. 


Ts When the 'D” bit is set, the ’I’ bit is used by the AC to 
communicate to the WIP how DSCP QoS is to be enforced on the 
station’s packet (inner) header. Details on the behavior of 
the 'I' bit are specified in Section 2.6.1.2. 


QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 
element contains four QoS sub-elements, one for every QoS profile. 
The order of the QoS profiles are Voice, Video, Best Effort, and 
Background. 


0 1 2 3 
0.1::2.3:4 50: 67 8-9-0 1.2.34 5:67 8 9 0.1:2 34 0:64 08 9:01 
E 


| Queue Depth | CWMin | CWMax | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Queue Depth: The number of packets that can be on the specific 
QoS transmit queue at any given time. 


CWMin: The Contention Window minimum (CWmin) value for the Qos 
transmit queue. The value of this field comes from the IEEE 
802.11 dot11EDCATableCWMin MIB element (see 
[IEEE.802-11.2007]). 


CWMax: The Contention Window maximum (CWmax) value for the Qos 
transmit queue. The value of this field comes from the IEEE 
802.11 dot11EDCATableCWMax MIB element (see 
[IEEE.802-11.2007]). 


AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the 
QoS transmit queue. The value of this field comes from the 
IEEE 802.11 dot11EDCATableAIFSN MIB element (see 
[IEEE.802-11.2007]). 
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6. 


23. 


Reserved: All implementations complying with this protocol MUST 
set to zero any bits that are reserved in the version of the 
protocol supported by that implementation. Receivers MUST 
ignore all bits not defined for the version of the protocol 
they support. 


8021p: The 3-bit 802.1p priority value to use if packets are to 
be IEEE 802.1p tagged. This field is used only if the ’P’ bit 
is set; otherwise, its contents MUST be ignored. 


RSV: All implementations complying with this protocol MUST set 
to zero any bits that are reserved in the version of the 
protocol supported by that implementation. Receivers MUST 
ignore all bits not defined for the version of the protocol 
they support. 


DSCP Tag: The 6-bit DSCP label to use if packets are eligible to 
be DSCP tagged, specifically an IPv4 or IPv6 packet (see 
[RFC2474]). This field is used only if the 'D” bit is set; 


otherwise, its contents MUST be ignored. 


IEEE 802.11 WTP Radio Configuration 


The IEEE 802.11 WTP WLAN Radio Configuration message element is used 
by the AC to configure a Radio on the WTP, and by the WTP to deliver 
its radio configuration to the AC. The message element value 
contains the following fields: 


0 
0 


Į 6 7 
+-+-+- E 
+ 


Short Preamble| Num of BSSIDs | DTIM Period | 
+-+-+-+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| BSSID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| BSSID | Beacon Period 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Country String 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+— + — +— + 


Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 


Length: 16 


Radio ID: An 8-bit value representing the radio to configure, whose 


value is between one (1) and 31. 
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Short Preamble: An 8-bit value indicating whether short preamble is 
supported. The following enumerated values are currently 
supported: 

0 - Short preamble not supported. 
1 - Short preamble is supported. 
BSSID: The WLAN Radio’s base MAC Address. 
Number of BSSIDs: This attribute contains the maximum number of 


BSSIDs supported by the WIP. This value restricts the number of 
logical networks supported by the WIP, and is between 1 and 16. 


DTIM Period: This attribute specifies the number of Beacon 
intervals that elapse between transmission of Beacons frames 
containing a Traffic Indication Map (TIM) element whose Delivery 
Traffic Indication Message (DTIM) Count field is 0. This value is 
transmitted in the DTIM Period field of Beacon frames. The value 
of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 
element (see [IEEE.802-11.2007]). 


Beacon Period: This attribute specifies the number of Time Unit 
(TU) that a station uses for scheduling Beacon transmissions. 
This value is transmitted in Beacon and Probe Response frames. 
The value of this field comes from the IEEE 802.11 
dotl1llBeaconPeriod MIB element (see [IEEE.802-11.2007]). 


Country String: This attribute identifies the country in which the 
station is operating. The value of this field comes from the IEEE 
802.11 dot1ilCountryString MIB element (see [IEEE.802-11.2007]). 
Some regulatory domains do not allow WIPs to have user 
configurable country string, and require that it be a fixed value 
during the manufacturing process. Therefore, WTP vendors that 
wish to allow for the configuration of this field will need to 
validate this behavior during its radio certification process. 
Other WTP vendors may simply wish to treat this WTP configuration 
parameter as read-only. The country strings can be found in 
[ISO.3166-1]. 


The WIP and AC MAY ignore the value of this field, depending upon 
regulatory requirements, for example to avoid classification as a 
Software-Defined Radio. When this field is used, the first two 
octets of this string is the two-character country string as 
described in [150.3166-1], and the third octet MUST either be a 
space, '0', 'I', or X” as defined below. When the value of the 
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third octet is 255 (HEX Oxff), the country string field is not 
used, and MUST be ignored. The following are the possible values 
for the third octet: 


1. an ASCII space character, if the regulations under which the 
station is operating encompass all environments in the 
country, 

2i an ASCII ’0O’ character, if the regulations under which the 


station is operating are for an outdoor environment only, or 


3. an ASCII 'I' character, if the regulations under which the 
station is operating are for an indoor environment only, 


4. an ASCII 'X” character, if the station is operating under a 
non-country entity. The first two octets of the non-country 
entity shall be two ASCII 'XX” characters, 


De a HEX Oxff character means that the country string field is 
not used and MUST be ignored. 


Note that the last byte of the Country String MUST be set to NULL. 
6.24. IEEE 802.11 WIP Radio Fail Alarm Indication 


The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 
sent by the WIP to the AC when it detects a radio failure. 


0 1 2 3 
0-2 23.4 56 18 OO - L234 oO PB Or OL. 23) A 3.6 78:90 1 
FPP atta tata a o 

| Radio ID | Type | Status | Pad 
FFP rt ata tata tartar a o o o E O 


Type: 1047 for IEEE 802.11 WIP Radio Fail Alarm Indication 
Length: 4 
Radio ID: The Radio Identifier, whose value is between one (1) and 


31, typically refers to some interface index on the WTP. 


Type: The type of radio failure detected. The following enumerated 
values are supported: 


1 - Receiver 


2 - Transmitter 
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Status: An 8-bit boolean indicating whether the radio failure is 
being reported or cleared. A value of zero is used to clear the 
event, while a value of one is used to report the event. 


Pad: All implementations complying with version zero of this 
protocol MUST set these bits to zero. Receivers MUST ignore all 
bits not defined for the version of the protocol they support. 


6.25. IEEE 802.11 WIP Radio Information 


The IEEE 802.11 WTP Radio Information message element is used to 
communicate the radio information for each IEEE 802.11 radio in the 
WIP. The Discovery Request message, Primary Discovery Request 
message, and Join Request message MUST include one such message 
element per radio in the WIP. The Radio-Type field is used by the AC 
in order to determine which IEEE 802.11 technology specific binding 
is to be used with the WIP. 


The message element contains two fields, as shown below. 
0 1 2 3 


0-1.:2-3.4 .0: 6-7 8: 9 011.2 .3.4.5-6:7.8 901.2 32.0.6 778: 9 0: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Radio ID | Radio Type | 
+-+-+-+-+-+-+-+-+-+-+-+ +H 
| Radio Type | 


+-+-+-+-+-+-+-+-+ 


Type: 1048 for IEEE 802.11 WTP Radio Information 
Length: 5 
Radio ID: The Radio Identifier, whose value is between one (1) and 


31, which typically refers to an interface index on the WTP. 


Radio Type: The type of radio present. Note this is a bit field 
that is used to specify support for more than a single type of 
PHY/MAC. The field has the following format: 


01234567 
dh ho ho o ho +++ 
|Reservd|N|G|A|B| 
++ ho ho o o o ++ 
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Reservd: A set of reserved bits for future use. All 
implementations complying with this protocol MUST set to zero 
any bits that are reserved in the version of the protocol 
supported by that implementation. Receivers MUST ignore all 
bits not defined for the version of the protocol they support. 

N: An IEEE 802.11n radio. 

G: An IEEE 802.11g radio. 

A: An IEEE 802.11la radio. 

B: An IEEE 802.11b radio. 


7. IEEE 802.11 Binding WTP Saved Variables 


This section contains the IEEE 802.11 binding specific variables that 
SHOULD be saved in non-volatile memory on the WTP. 


7.1. IEEE80211AntennaInfo 
The WIP-per-radio antenna configuration, defined in Section 6.2. 
7.2. IEEE80211DSControl 


The WIP-per-radio Direct Sequence Control configuration, defined in 
Section 6.5. 


7.3.  IEEE80211MACOperation 


The WIP-per-radio MAC Operation configuration, defined in 
Section 6.7. 


7.4. IEEE802110FDMControl 


The WIP-per-radio OFDM MAC Operation configuration, defined in 
Section 6.10. 


7.5. IEEE80211Rateset 


The WIP-per-radio Basic Rate Set configuration, defined in 
Section 6.11. 


7.6. IEEE80211TxPower 


The WIP-per-radio Transmit Power configuration, defined in 
Section 6.18. 
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7.7.  IEEE8021100S 


The WIP-per-radio Quality of Service configuration, defined in 
Section 6.22. 


7.8. IEEE80211RadioConfig 
The WIP-per-radio Radio Configuration, defined in Section 6.23. 
8. Technology Specific Message Element Values 
This section lists IEEE 802.11-specific values for the generic CAPWAP 


message elements that include fields whose values are technology 
specific. 


8.1. WIP Descriptor Message Element, Encryption Capabilities Field 


This specification defines two new bits for the WIP Descriptor’s 
Encryption Capabilities field, as defined in [RFC5415]. Note that 
only the bits defined in this specification are described below. WEP 
is not explicitly advertised as a WIP capability since all WTPs are 
expected to support the encryption cipher. The format of the 
Encryption Capabilities field is: 


{i 
0123456789012345 
E 
| [alt] | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. 
T; WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] 


and [WPA], respectively. 
9. Security Considerations 
This section describes security considerations for using IEEE 802.11 
with the CAPWAP protocol. A complete threat analysis of the CAPWAP 
protocol can also be found in [RFC5418]. 
9.1. IEEE 802.11 Security 
When used with an IEEE 802.11 infrastructure with WEP encryption, the 


CAPWAP protocol does not add any new vulnerabilities. Derived 
Session Keys between the STA and WIP can be compromised, resulting in 
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many well-documented attacks. Implementers SHOULD discourage the use 
of WEP and encourage the use of technically-sound cryptographic 
solutions such as those in an IEEE 802.11 RSN. 


STA authentication is performed using IEEE 802.1X, and consequently 
EAP. Implementers SHOULD use EAP methods meeting the requirements 
specified [RFC4017]. 


When used with IEEE 802.11 RSN security, the CAPWAP protocol may 
introduce new vulnerabilities, depending on whether the link security 
(packet encryption and integrity verification) is provided by the WTP 
or the AC. When the link security function is provided by the AC, no 
new security concerns are introduced. 


However, when the WIP provides link security, a new vulnerability 
will exist when the following conditions are true: 


o The client is not the first to associate to the WIP/ESSID (i.e., 
other clients are associated), a GTK already exists, and 


o traffic has been broadcast under the existing GTK. 


Under these circumstances, the receive sequence counter (KeyRSC) 
associated with the GTK is non-zero, but because the AC anchors the 
4-way handshake with the client, the exact value of the KeyRSC is not 
known when the AC constructs the message containing the GTK. The 
client will update its Key RSC value to the current valid KeyRSC upon 
receipt of a valid multicast/broadcast message, but prior to this, 
previous multicast/broadcast traffic that was secured with the 
existing GTK may be replayed, and the client will accept this traffic 
as valid. 


Typically, busy networks will produce numerous multicast or broadcast 
frames per second, so the window of opportunity with respect to such 


replay is expected to be very small. In most conditions, it is 
expected that replayed frames could be detected (and logged) by the 
WTP. 


The only way to completely close this window is to provide the exact 
KeyRSC value in message 3 of the 4-way handshake; any other approach 
simply narrows the window to varying degrees. Given the low relative 
threat level this presents, the additional complexity introduced by 
providing the exact KeyRSC value is not warranted. That is, this 
specification provides for a calculated risk in this regard. 
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10. 


10. 


10 


10. 


The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 
802.11i handshake, unless the AC has knowledge of a more optimal RSC 
value to use. Mechanisms for determining a more optimal RSC value 
are outside the scope of this specification. 


IANA Considerations 


This section details the actions IANA has taken per this 
specification. There are numerous registries that have been be 
created, and the contents, document action (see [RFC5226], and 
registry format are all included below. Note that in cases where bit 
fields are referred to, the bit numbering is left to right, where the 
leftmost bit is labeled as bit zero (0). 


1. CAPWAP Wireless Binding Identifier 
This specification requires a value assigned from the Wireless 


Binding Identifier namespace, defined in [RFC5415]. (1) has been 
assigned (see Section 2.1, as it is used in implementations. 


.2. CAPWAP IEEE 802.11 Message Types 


IANA created a new sub-registry in the existing CAPWAP Message Type 
registry, which is defined in [RFC5415]. 


IANA created and maintains the CAPWAP IEEE 802.11 Message Types 
sub-registry for all message types whose Enterprise Number is set to 
13277. The namespace is 8 bits (3398912-3399167), where the value 
3398912 is reserved and must not be assigned. The values 3398913 and 
3398914 are allocated in this specification, and can be found in 
Section 3. Any new assignments of a CAPWAP IEEE 802.11 Message Type 
(whose Enterprise Number is set to 13277) require an Expert Review. 
The format of the registry maintained by IANA is as follows: 


CAPWAP IEEE 802.11 Message Type Reference 
Control Message Value 


3. CAPWAP Message Element Type 


This specification defines new values to be registered to the 
existing CAPWAP Message Element Type registry, defined in [RFC5415]. 
The values used in this document, 1024 through 1048, as listed in 
Figure 8 are recommended as implementations already exist that make 
use of these values. 
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10. 


10. 


10. 


10. 


4. IEEE 802.11 Key Status 


The Key Status field in the IEEE 802.11 Add WLAN message element (see 
Section 6.1) and IEEE 802.11 Update WLAN message element (see 

Section 6.21) is used to provide information about the status of the 
keying exchange. This document defines four values, zero (0) through 
three (3), and the remaining values (4-255) are controlled and 
maintained by IANA and requires an Expert Review. 


5. IEEE 802.11 QoS 


The QoS field in the IEEE 802.11 Add WLAN message element (see 
Section 6.1) is used to configure a QoS policy for the WLAN. The 
namespace is 8 bits (0-255), where the values zero (0) through three 
(3) are allocated in this specification, and can be found in 

Section 6.1. This namespace is managed by IANA and assignments 
require an Expert Review. IANA created the IEEE 802.11 QoS registry, 
whose format is: 


TEEE 802.11 QoS Type Value Reference 
6. IEEE 802.11 Auth Type 


The Auth Type field in the IEEE 802.11 Add WLAN message element (see 
Section 6.1) is 8 bits and is used to configure the IEEE 802.11 
authentication policy for the WLAN. The namespace is 8 bits (0-255), 
where the values zero (0) and one (1) are allocated in this 
specification, and can be found in Section 6.1. This namespace is 
managed by IANA and assignments require an Expert Review. IANA 
created the IEEE 802.11 Auth Type registry, whose format is: 


IEEE 802.11 Auth Type Type Value Reference 
7. IEEE 802.11 Antenna Combiner 


The Combiner field in the IEEE 802.11 Antenna message element (see 
Section 6.2) is used to provide information about the WTP’s antennas. 
The namespace is 8 bits (0-255), where the values one (1) through 
four (4) are allocated in this specification, and can be found in 
Section 6.2. This namespace is managed by IANA and assignments 
require an Expert Review. IANA created the IEEE 802.11 Antenna 
Combiner registry, whose format is: 


IEEE 802.11 Antenna Combiner Type Value Reference 
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10. 


10. 


10. 


8. IEEE 802.11 Antenna Selection 


The Antenna Selection field in the IEEE 802.11 Antenna message 
element (see Section 6.2) is used to provide information about the 
WIP’s antennas. The namespace is 8 bits (0-255), where the values 
zero (0) is reserved and used and the values one (1) through two (2) 
are allocated in this specification, and can be found in Section 6.2. 
This namespace is managed by IANA and assignments require an Expert 
Review. IANA created the IEEE 802.11 Antenna Selection registry, 
whose format is: 


TEEE 802.11 Antenna Selection Type Value Reference 
9. IEEE 802.11 Session Key Flags 


The flags field in the IEEE 802.11 Station Session Key message 
element (see Section 6.15) is 16 bits and is used to configure the 
session key association with the mobile device. This specification 
defines bits zero (0) and one (1), while bits two (2) through fifteen 
are reserved. The reserved bits are managed by IANA and assignment 
requires an Expert Review. IANA created the IEEE 802.11 Session Key 
Flags registry, whose format is: 


TEEE 802.11 Station Session Key Bit Position Reference 
10. IEEE 802.11 Tagging Policy 


The Tagging Policy field in the IEEE 802.11 WIP Quality of Service 
message element (see Section 6.22) is 8 bits and is used to specify 
how the CAPWAP Data Channel packets are to be tagged. This 
specification defines bits three (3) through seven (7). The 
remaining bits are managed by IANA and assignment requires an Expert 
Review. IANA created the IEEE 802.11 Tagging Policy registry, whose 
format is: 


IEEE 802.11 Tagging Policy Bit Position Reference 
Ti IEEE 802.11 WTP Radio Fail 


The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication 
message element (see Section 6.24) is used to provide information on 
why a WIP’s radio has failed. The namespace is 8 bits (0-255), where 
the value zero (0) is reserved and unused, while the values one (1) 
and two (2) are allocated in this specification, and can be found in 
Section 6.24. This namespace is managed by IANA and assignments 
require an Expert Review. IANA created the IEEE 802.11 WTP Radio 
Fail registry, whose format is: 
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10. 


LT, 


12 


12:5 


TEEE 802.11 WTP Radio Fail Type Value Reference 


12. IEEE 802.11 WIP Radio Type 


The Radio Type field in the IEEE 802.11 WIP Radio Information message 
element (see Section 6.25) is 8 bits and is used to provide 
information about the WTP’s radio type. This specification defines 
bits four (4) through seven (7). The remaining bits are managed by 
IANA and assignment requires an Expert Review. IANA created the IEEE 
802.11 WTP Radio Type registry, whose format is: 


IEEE 802.11 WIP Radio Type Bit Position Reference 
13. WTP Encryption Capabilities 


The WIP Encryption Capabilities field in the WIP Descriptor message 
element (see Section 8.1) is 16 bits and is used by the WTP to 
indicate its IEEE 802.11 encryption capabilities. This specification 
defines bits 12 and 13. The reserved bits are managed by IANA and 
assignment requires an Expert Review. IANA created the IEEE 802.11 
Encryption Capabilities registry, whose format is: 


IEEE 802.11 Encryption Capabilities Bit Position Reference 
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